I just tested this on OS X, which doesn't expose printers through /dev/ in the way you're describing as far as I can tell. But apparently lp exists on OS X, so you can do echo "Hello printer" | lp -d <printer_name>, and find the name through lpstat -p.
And sure enough, this works! Just tested on my new printer.
Wow! What a delightful exchange this is! Curiosity asked and answered in 12 minutes! I literally got goosebumps on my arms as I read your comment and reached the last part where you say "this works!"
With macOS there is this one off topic thing regarding printing that always gets me. I once had a company Macbook and it connected to my old Brother printer without problems and only then (after almost ten years of having the printer) I discovered it has double sided printing. It just worked. I always wondered if there is a way to connect somehow to this machinery to get a macOS printer driver or whatever and emulate whatever is needed for this to work on Linux.
IIRC, Apple employed the maintainer[1] of CUPS - which is/was available on MacOS for network printing, and has been available on Linux for even longer. I would be surprised if the feature was not available on Linux for your printer.
Edit: added footnote
1. The chief maintainer - not the only maintainer, between 2007-2019
What would be the use case of this? I have a remarkable 2 and there's the official Read on Remarkable extension that automatically sends a pdf of the page you're on or the book or whatever to your Remarkable. I'm not sure if it works on Remarkable 1 but there isn't any documentation on it being unsupported.
They disabled it by default as part of security hardening a few releases back. Probably around the same time they stopped shipping PHP and other stuff.
CUPS is still running the printing in the background, its just the web UI that's been disabled. IIRC.
I know about CUPS. There is no real alternative on Linux, is there? But it doesn't work like on macOS. I am sure they added some of magic on top.
On macOS I think it either recognized my printer or I had to select it from a list. I don't remember which for sure. It was a few years ago.
On Linux my Brother printer is not on the list. Brother offers a deb and rpm packages which may be obsolete for all I know. Then you have to install it manually. But in my case it never offered double sided printing.
For years I am using a crutch in terms of Android driver and Brother's own app. This despite being offered by the producer doesn't offer double sided printing either. It doesn't even give ability to print in grayscale.
> I know about CUPS. There is no real alternative on Linux, is there?
I don't know what lifting "real" is doing here, but lpd(8)[0] (line printer daemon) is what we used to use, and printcap(5)[1] to configure. It was general enough that you could make a music playlist system out of it[2].
Dunno about your printer but with my Brother Laser the CUPS driver can do double-sided printing on Linux just fine.
But you should in theory also be able to do this without any Brother-specific driver since pretty much all modern printers speak IPP for mobile device compatibility.
Usually, drivers for similar printers might work. There are also generic driver sets like Gutenprint. Nonetheless, note that CUPS now discourages the use of any drivers, and support will be removed in the future.
They claim that modern printers implement IPP and that should be the preferred protocol for printing. In IPP, printers advertise capabilities and are able to handle different high-level printing requests.
That is wrong. CUPS recommends using the IPP protocol, but the IPP driver (called “IPP Everywhere”) is only available on relatively modern printers. Everything else still has to use drivers, mostly PPD.
Any CUPS daemon will raise the following warning on startup. I just copied this from my Systemd log:
cupsd[873]: Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups/issues/103
Not saying this is the correct decision, but IPP Everywhere is available on most printers that are < 10 years old. Obviously, that rules out older printers, which are fairly common.
> As for printer drivers, those few printers that "need" them can migrate to standalone applications/services using the CUPS API to provide an IPP Everywhere-compatible Printer instance. PAPPL provides a convenient framework for easily creating these applications and porting existing CUPS raster drivers, and the following printer applications are already available or (in the case of Gutenprint) under development:
[...]
> ps-printer-app: PAPPL-based PostScript printer application that supports all CUPS/PostScript printers via PPDs and includes all of the Foomatic and HPLIP drivers.
So drivers will still be supported in a sense, just not directly by the CUPS daemon.
I have a Brother printer from 2019 (HL 2340) that does not support IPP Everywhere. A lot of other printers from before ~2020 don’t either.
You are (like so many other people) confusing IPP the protocol with IPP the driver, which is honestly not your fault and a terrible naming mistake.
And like you mentioned, people have way older printers because if all you do is print monochrome and mostly text, a printer from 2004 doesn’t lack much aside from AirPrint / Mopria. Which is why I suspect CUPS will not deprecate at least PPD drivers.
If you read the linked issue you will see that the plan for legacy printers is to move the printer drivers under a separate application that CUPS can then talk IPP to.
So yes, CUPS itself will only support IPP without any printer-specific driver. Since mobile phones also only directly support IPP this sounds like a reasonable decision.
> If you read the linked issue you will see that the plan for legacy printers is to move the printer drivers under a separate application that CUPS can then talk IPP to.
Ah, yes. Thanks for pointing that out! I wonder how much more secure that will make things for those who have to use legacy printers.
> Since mobile phones also only directly support IPP
Technically AirPrint is not IPP Everywhere, they use a different raster format and some different glue. For example my Brother printer supports AirPrint but fails ~50% of the IPP Everywhere self-certification tests. But that’s splitting hairs.
Huh, my first thought was that it ought to be somewhat mechanically obvious if the printer supports double sided printing. But now I’m thinking, some printers do just magically suck the paper back in for the second side, right? And I’m wondering if my printer might secretly support double sided printing as well.
The question then is, does this lp utility just feed the text directly to the printer or is it just a legacy compatibility layer that goes through the normal printing APIs to do its thing.
And sure enough, this works! Just tested on my new printer.