Leap 15 Unable to print from CLI

All, I have installed a Lexmark printer. Printing using the GUI such as ‘Print Test Page’,
or opening a text file in GUI such as Kate prints fine. If I try to print to the same queue
using the CLI nothing happens.

Output from CLI:

user@server:/> lp test.file

request id is lexb-14 (1 file(s))

user@server:/>

Nothing prints.

user@server:/> lpstat -p -d

printer lexb is idle. enabled since Fri 12 Oct 2018 04:54:00 PM
system default destination: lexb

user@server:/> lp -d lexb test.file
request id is lexb-15 (1 file(s))

user@server:/>

Nothing prints.

CLI broken, GUI printing fine.

I don’t print much. But it has worked for me from the command line when I have tried (current an HP printer). But I think I used “lpr” rather than “lp” for printing.

Same result.

Does your text file print successfully if you use a2ps? This utility will process a given text file and convert it to PS before sending it to a default printer.

a2ps test.file

What MIME-type is reported by the following?

file -i  -b test.file

This may be of interest…
https://en.opensuse.org/SDB:Using_Your_Own_Filters_to_Print_with_CUPS
In particular, see the section about printing plain text files…

CUPS default filtering works in general by way of the entries defined in /usr/share/cups/mime/mime.types or /etc/cups/mime.types and /usr/share/cups/mime/mime.convs or /etc/cups/mime.convs. Where appropriate for each printing queue, the *cupsFilter entries in the PPD file are used.

and also some useful info about MIME types here…
https://en.opensuse.org/SDB:CUPS_in_a_Nutshell

Since CUPS 1.3.4 only UTF-8 text is supported (which includes 7-bit ASCII text). Text in the ISO-8859 encodings is no longer supported. The reason is that it is not possible to autodetect the encoding so that CUPS cannot process “plain text” files in arbitrary encodings in a reliable way, see SDB:Plain Text versus Locale. To print non-UTF-8 text, you must convert it from its encoding to UTF-8 before sending it to the CUPS server. To print an ISO-8859-1 text file, you may use:iconv -f ISO-8859-1 -t UTF-8 filename | lp -d queue
See “iconv --help” for some information about iconv.
Printing of PDF or graphics files (JPEG, PNG, etc.) works as before.

I cannot for the life of me understand why this is so complicated???
Printing with ‘lp filename’ has been a standard feature on *nix for over 40 years.
If I vim a test file, save it and try to print it with lp it should darn well do it. Anything
less is just dumb. You are trying to tell me the latest and greatest OS cannot print a simple text file
out of the box? Just wow. SUSE has taken a leap alright, right off the deep end.

Since you are still having problems, I just tried as a test. I did:

lpr .cshrc

That’s my shell startup file (I use “csh”).

It printed just fine.

I used that as a test file, because it is just plain text with no fancy encoding.

Same here. Again, I’d like to see the output of the command I requested from my previous post re MIME type.

user@server:~>file -i -b test
text/plain; charset=us-ascii 

Just tried it again using ‘lpr test’, same result.
If I open the file in something like kwrite I can print it just fine.

Also just tried printing the file as root, same result.

Apparently the Lexmark drivers are garbage for the MS811.
I switched to Generic PCL 4 driver and now it prints from CLI and GUI.
Shouldn’t make a difference but apparently it does.

That looks as expected. The next step is to examine the CUPS error log after submitting the CLI print job. Before doing that, put CUPS into debug mode for verbose reporting.

sudo cupsctl --debug-logging

As /var/log/cups/error_log can be lengthy, just submit the portion relating to the last print job. Upload to https://susepaste.org/, change the ‘Delete After’ time to a sensible value, and post the link that it generates here. That might help with finding out where the issue is occurring.

Ah, that is good to know.

That would pretty much explain the problems you are seeing.

Yes, not a CUPS issue, and definitely not an openSUSE-specific issue either. :wink: