Hacker News new | ask | show | jobs
by whartung 622 days ago
So, curiosity today.

One of the things that this person does is simply echo to /dev/lp0.

Which is all you did back in the day. Shove text down the interface, and the printer printed.

Now, while we have very fancy modern printers, they're still printers with a long legacy. Even back in the day, early HP laser printers worked like this. Shove data down the wire, and it printed (Courier 10, 66 lines per page). Only the Apple Laserwriter didn't really do this (I don't think) because it was an exclusively PostScript printer. Instead, you shoved PostScript down the wire.

As the printers evolved, the language that was sent to them got more complicated. But even so, they still had a long line of backward compatibility.

So, if I plug a USB printer into a computer, and ls > /dev/usbXXX, will it print today? Does that still "just work"?

If I do that with an EPSON and send it EPSON MX-80 escape codes -- does it still work? It wouldn't surprise me either way, but I'm just curious if someone knows. They're very black boxy today (to me anyway).

(Anyone else remember the joys of getting reports to fit on pre-printed, multi-copy NCR forms? What fun that was!)

18 comments

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

I used this (CUPS) to add my Remarkable 1 as a Printer in MacOS. Worked like a charm, nothing to install on the laptop…
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.

extension link: https://chromewebstore.google.com/detail/Read%20on%20reMarka...

Please share details! My wife has one of those, and this sounds like a great way to get more use out of it.
> which is/was available on MacOS for network printing

Very much IS there in the background.

See http://localhost:631/printers on your OS X machine.

I thought the default was disabled at some point. On my macOS laptop, I get:

> Web Interface is Disabled

> The web interface is currently disabled. Run “cupsctl WebInterface=yes” to enable it.

But I cannot remember if I disabled that.

> But I cannot remember if I disabled that.

Its ok, you're not going mad. ;)

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.

Safari can’t open the page “‎localhost:631/printers” because Safari can’t connect to the server “localhost”.
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].

[0] https://man.netbsd.org/lpd.8

[1] https://man.netbsd.org/printcap.5

[2] https://patrick.wagstrom.net/weblog/2003/05/23/lpdforfunandm...

On Linux, Brother also has a generic driver (brgen1mlr, or something like that). You’ll need to install both the driver and cupswrapper though.

If you install the specific driver it generally should have parity with their Windows / macOS driver though.

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.
Are you using Brother's Linux printer driver for your device? If not, I'd start there.

https://support.brother.com/g/b/midlink_productcategory.aspx...

It never offered the option in my case.
If it’s a Brother, the features are in the suffix of the model name: D for duplexer, C for color, N for network (wired), W for wireless networking.
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.
Exactly this magical sucking the paper back. I was amazed.
Mine did not. I am, therefore, non-amazed. Mazed?
Whelmed.
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.
Works for me as well. This is a network printer available via WiFi.
I tried with my HP M15w, also through WiFi. Sure enough, it worked. This may be a little project for tomorrow.
> One of the things that this person does is simply echo to /dev/lp0.

> So, if I plug a USB printer into a computer, and ls > /dev/usbXXX, will it print today? Does that still "just work"?

Both of the following worked for me:

  printf 'hello\f' > /dev/usb/lp0
  printf 'hello\f' | nc -N $printer_ip 9100
This is on a Brother laser printer. Its programming guide is linked next to its manual online. The language is PCL, but you don't really need to know much about it to get simple stuff printed.

Neither of the above involve CUPS. Using the `lp`/`lpr` executable like in other comments requires the printer to be registered with CUPS first.

For `ls >`, the printer expects DOS line endings. `\n` just moves to a new line without "returning the carriage", so you need to pipe through `sed 's/$/\r/'` or use `nc -C`.

With the USB connection, you can print multiple times to build a single page and it won't come out until you provide the form feed. With the TCP connection, the page will be printed when the connection is closed.

> Using the `lp`/`lpr` executable like in other comments requires the printer to be registered with CUPS first.

In modern Linux distros, lp/lpd are usually shims provided for backward compatibility, but it doesn't have to be that way. For example FreeBSD seems to provide support for lpd without for cups [1], although I don't see any real advantage in doing that.

[1] https://docs.freebsd.org/en/books/handbook/printing/

OpenBSD does as well. The advantage is you don’t need CUPS.
But you do still need to register the printer prior to using, or at least have a basic registration set up that works with it.
I have an Epson LX-350, bought new a few years ago. It connects via USB (but there's also serial and parallel ports). When connected via usb it appeared as /dev/usblp0 or something like that, and yes just cat'ing to it worked. And presumably the customers who buy these things new want them compatible with whatever processes they already have (for the last 30-50 years), so it supports both ESC/P 2 as you'd expect and IBM's escape codes (which I didn't expect and the old matrix printers I had from the 90's didn't).

What's perhaps more surprising, my macbook had an inbuilt driver for generic epson printers and it worked. It was not very good, it printed as graphics but it was there for some reason.

Not sure about modern inkjet and laser printers though. An inkjet Epson I used to have once did support raw ESC/P codes though, but it was 20 years ago.

You can even do this with network printers, netcat a pdf to the open port and it will print.

https://retrohacker.substack.com/p/bye-cups-printing-with-ne...

Just did this with my HP Envy injket and it worked, had no idea this was a thing it's very cool.
Yeah, I'm surprised this works. I expected some complex printer-specific reverse engineered protocol.
The modern "protocol" is PDF. That's what everyone standardised on during the rise of smartphones and needing to have them able to print.

PDF includes pretty much all the printer needs, like pagesize, colour palette, font information, etc.

It's not the greatest format in the world... But everyone can shove in one of dozens of PDF parsing libraries without a lot of effort. So it happened.

The document format is PDF (or postscript before that), the protocol is IPP.
Back when I was at school in the 1990s, there was a dot matrix printer in the computer room still, which was the default printer for any of the computers on the network. One of the classic user errors was that somebody would try to print a document from Word and it would send a load of PostScript to the dot matrix printer, which would dutifully print it all out as PostScript source, wasting paper and printer ribbon until somebody told the printer to stop...
So, if I plug a USB printer into a computer, and ls > /dev/usbXXX, will it print today? Does that still "just work"?

For those who want to look into the horse's mouth, USB printing device class:

https://www.usb.org/sites/default/files/usbprint11a021811.pd...

"Printers have two different types of commands: those that transfer data, and those that control the USB interface or printer interface. The host prints something on a printer by delivering data on the Bulk OUT endpoint. This data may take the form of PostScript, HP PCL, or any other PDL. This data may also be encapsulated in a PCP, such as IEEE 1284.1, or something that is vendor-specific. In addition, the data may also be simple text, or it may be a proprietary PDL."

The rest of the spec makes it very clear that this is intended to work exactly like a standard parallel port at the "application layer". Use the bulk OUT endpoint to write data to the printer, and the bulk IN to read data from it. There is a status request that returns the same signals (out of paper, etc.) that a parallel port has.

If I do that with an EPSON and send it EPSON MX-80 escape codes -- does it still work?

ESC/P and ESC/P2 which followed are backwards-compatible and based on the MX, so likely yes.

> Only the Apple Laserwriter didn't really do this (I don't think) because it was an exclusively PostScript printer. Instead, you shoved PostScript down the wire.

It would be possible to write a PostScript program that emulates ESC/P (or PCL), although then you would have to send an entire page (or a page break) before the page would be printed, unlike the old dot-matrix line printers that you can print one line at a time, PostScript can only print one page at a time.

Its not like a laser printer can really print line by line though.
An old HP laser printer will buffer plain text line-by-line, and will print a page once the last line is buffered.

That buffer could have several random programs' outputs in it, all just dumped as simply as possible to /dev/lp0 (or lpt1 or whatever), and it works.

A LaserWriter can't do these things.

>will print a page once the last line is buffered.

You could usually set a timeout to eject the page if no data had been received for a while.

>A LaserWriter can't do these things.

The LaserWriter could emulate a Diablo printer which would do the same thing. It wouldn't accept PostScript then though.

Well, that's easy to check out as long as you have a printer connected. It's going to depend on the printer. Doesn't work on my Brother laser printer on Linux, even if I send some valid Postscript to /dev/usb/lp0 . Piping it to lpr works of course, as long as you have a default printer selected.

Once you've established that you can print basic text, you can expect that the printer's escape codes will work.

Doesn't work on my Brother laser printer on Linux, even if I send some valid Postscript to /dev/usb/lp0

It's probably expecting ESC/P or PCL. Laser printers also usually wait for a formfeed before they will process a page.

Thanks. Adding a formfeed resulted in an empty page, so there are clearly possibilities but since I can't find a quick PCL example[0] and lpr suits me fine I'm not going to investigate further.

[0] I'm assuming PCL is most likely supported, and I remember having worked with an EPSON dot-matrix printer (i.e. probably using ESC/P) in 8-bit days and that it didn't require special commands to print basic text.

> So, if I plug a USB printer into a computer, and ls > /dev/usbXXX, will it print today? Does that still "just work"?

I can't attest to whether piping directly to the device works, but I routinely do stuff like

    lpr -o raw -P $SOME_CUPS_PRINTER < $SOME_FILE
Back when I was doing warehouse IT work I'd hand-write ZPL code and shove it directly into Zebra printers for things like asset tags, printed instructions on equipment, etc. This was also my approach for various tools I wrote to automate the printing of packing slips and shipping labels - except these programs had to run on Windows machines, and I tell ya hwat Windows sure doesn't make it as easy as CUPS does.

More recently I dusted off that particular skillset in order to print a bunch of labels for my kitchen. ZPL really ain't that bad of a language; sure beats trying to write PostScript or PCL by hand :)

> So, if I plug a USB printer into a computer, and ls > /dev/usbXXX, will it print today? Does that still "just work"?

Many commented that it still works... This brought back good memories of sending native PostScript files to an HP LaserJet 4M+'s IP address, over the LAN, using netcat. Amazing stuff.

The gotcha of course is when the shit hits the fan: it can quickly degenerate into pages upon pages of garbage getting printed.

On the plus side back when things were, and still are, simple like that, typically just turning the printer of and terminating the command and you'd be good to go. As opposed to, say, weird spoolers/cache sometimes relaunching print jobs people thoughts were long gone.

> it can quickly degenerate into pages upon pages of garbage getting printed

This is still a thing... I was setting up a modern Brother laser printer in FreeBSD (Brother only supplies Linux "PPDs" which run a bunch of binary blobs with Ghostscript and weird stuff) and figured it was easy enough so I did it remotely. Could only watch helplessly on the security camera as the printer spit out every page in it's paper cassette covered in junk... Remote stop commands did nothing.

God, that's a flashback. Desperately running NET STOP SPOOLER on an NT print server and then deleting some large SHD file because someone sent 789 pages of manuals to the printer. Sigh.
I wish we could go back to this uncomplicated UX. I just spent literally 2 hours setting up a brand new Epson ET-2850 printer for my dad. I'm quite disgusted at how slow, bloated and disjointed the process was. The printer ships with an android app, which worked fairly well, and, on the Epson website, some Microsoft Windows software, which was one of the worst software experiences I've ever had. The Wi-Fi setup is totally disjointed on the printer, app and windows release. You enter the Wi-Fi password via the app, which should then forward it to the printer. That's fine, it's better than using the dreadful printer interface. The printer saw the right SSID right away. No confirmation was given whether it connected or not. No big deal.

The software on their website was a Windows executable .exe file that seemed outdated even 10 years ago. To complete the last few steps, the printer network connection had to be set up once again, even though I had already previously connected it. Each attempt would take around 10-20 minutes, only to fail. The network errors and troubleshooting steps were incredibly generic and unhelpful. The worst part, until that point, was that the printer shipped with outdated firmware, and I did an online firmware update via the printer itself, confirming that the printer's Internet connection had indeed already been established. Rebooting the printer did not help. It turned out that, despite only just downloading the Windows executable that same hour from the Epson website, they were shipping an old version .exe, with some bug that causes the network setup to not be detected. However, it never prompted me to update. Only after restarting the Windows computer, and then re-opening the .exe, did some update trigger, and it allowed me to finish setting through to the last step of the installer to download the rest of the bloat and let the printer appear in the list of available printers on the network on the computer.

I then did a test print via an iPad. Took about 15 seconds.

Depends on when "back in the day" was; even in the mid-to-late 80s, especially if you were on a multi-user system, on BSD 4.2/4.3 local and networked printer access went through the Line Printer Daemon (still available on the BSDs).

For PostScript printers, there was a filter application (provided by Adobe) that would turn plain text (without the %! magic) into PostScript.

It's not installed by default, but the BSD (lp) interface is still available in Debian with

$ sudo apt-get install cups-bsd

Wow. That brings back a lot of memories. Those escape codes, figuring how to insert a form consistently (line it up with the mark on the left, maybe click it three times or press an insert button to suck it in a bit), then continual adjustments until things mostly fit. Good memories!
In my experience, inkjet printers can print line by line like teletypes, but laser printers can't.
I guess your printer driver is free to emulate an LPT if it wants to.
Thankfully even USB-connected printers emulate an LPT (see the other comment I left in this tree) and are very likely to accept one of the standard command sets as well as just plain ASCII.

It's similar to the terminal emulation situation: despite being decades old, the VT100 has become a de-facto terminal command set due to its popularity.

I wonder if this works with a sharp M205 I have in storage.
I discovered this in the most amusing way ever accidentally a few years ago.

https://x.com/normankev141/status/1146547923758538755?t=oZrj...

text of tweet: So I bought a networked printer recently and as you do decided to try connecting to it a few different undocumented ways. I tried telneting to it. It turns out that whatever you type, it prints typewriter style. That was a pleasant and hilarious surprise. #internetofshit