On 22 Mar 21:03, Ted Harding wrote:
<snippity class="quiteabit" />
One basic test is to switch the printer on, and then squirt a PostScript file, say "myfile.ps", using
cat myfile.ps > /dev/lp0
(or whatever the port is that your printer is connected to).
Not if it's a network printer you don't! ;)
In my experience, CUPS can be very tricky to get working, especially for "raw" files (i.e. sent to the printer as-is). The old LP system was much more straightforward.
The old system was lpr, not lp... lp is the binary provided by cups that acts almost like lpr.
CUPS is easy to configure as a raw printer, but not all apps print "postscript" any more, some print pdf instead - so having something like cups that will automagically translate it in the background is "rather handy". Also, most apps these days will automatically be able to find cups printers, whereas to use lpr they need to be told to spool to the lpr driver and that they have to print as postscript level 2.
When you are printing "raw", the main advantage of systems like LP or CUPS is that they send files to the printer via a queue directory, so that you can send more files while still waiting for the first file to finish printing, which the above "cat" command would not do -- though you could wrap it in a script which would look at a "queue" dirrectory, say "mylpq", take the least recent file therein and cat it to the printer (and stash it in a backup directory and delete it from the mylpq directory; and if it gets a succesful return from 'cat' then delete the backup).
In my experience, cups just works. But even if you don't want to use cups, then there's always lprng + magicfilter as an alternative.
I would *never* recommend reinventing the (several) existing wheels for printing, there's too many things that can (and will) go wrong, and then you're stuck with no support as no one is going to want to trawl through your hacky print spooler code and try to work out what the heck you've got completely totally wrong.
Cheers,