3 ms·

Ask HN: Why is the Linux shell purely textual?

1 points by ent101 6y ago

phendrenad2 6y ago
There's nothing stoping someone from making a Linux terminal that can contain images. The problem is you'd need to make a shell that's aware of how to wrap text around images, and you'd need a terminal app that can display them. And then you need terminal apps that know how to send images into this system.
- PaulHoule 6y ago
  See https://hyper.is https://hyper.is You would think you could type $ cat image.png and the terminal would see the "89 50 4e 47 0d 0a 1a 0a" and display the image inline, but it doesn't really work because a tty can get junk characters in it from other processes and images would get corrupted from time to time. I would point to https://en.wikipedia.org/wiki/Midnight_Commander https://en.wikipedia.org/wiki/Midnight_Commander as something that adds some simple GUI to the CLI experience.
pjc50 6y ago
Attempts have been made over the years at adding graphical capability: https://stackoverflow.com/questions/2114347/raster-graphics-in-xterm https://stackoverflow.com/questions/2114347/raster-graphics-... You have a chicken egg problem; you need to get people to want to use both a different shell and a different terminal emulator, at the same time. Textual mode fits well with all the tools. You can't grep an image sensibly.
ttyprintk 6y ago
The other answers give cutting-edge workarounds. Historically, the ancestor of Linux was developed in an environment where terminal standardization usually stripped out the marketable graphics features. Sound was single beeps, vocalized with ^G. If it seems overdue to standardize a real-time character-encoded graphics protocol, you can look at the Tektronix 4104 and descendants. That being said, typesetting was important early in UNIX. Even though the interface was command-line, UNIX implemented roff and maybe wouldn’t have succeeded if it couldn’t word-process into roff. Word processing was the first application for UNIX outside of the Labs.
- PaulHoule 6y ago
  Worse than that "the terminal" was originally a 110 bps. "Rm" was short for "REMOVE" because it would drive you crazy to wait for the printer to thunk away 6 times. The Bell Labs Technical journals is full of user studies for little things they could do to make UNIX users more productive. Even by 1990 it was likely to be 9600 bps, maybe you had a faster network and portable graphics X windows at a university lab. In the 1980s the Bell Labs folks had a rip-off of the Xerox PARC system that was network portable in the 1980's (see "Plan 9") but it was strange custom hardware and software that never really caught on.
simonblack 6y ago
Just like emojis can't transmit all the subtle nuances that words can, a textual interface is much more nuanced than a graphic shell. In practical terms, a graphic shell can only give you what the shell's programmer has envisaged is possible, and has given you a menu to include those specific things. That can't cover every single imaginable eventuality. If you don't believe that, try making a menu on paper that covers everything possible that a textual shell can do.

1 points by ent101 6y ago

There's nothing stoping someone from making a Linux terminal that can contain images. The problem is you'd need to make a shell that's aware of how to wrap text around images, and you'd need a terminal app that can display them. And then you need terminal apps that know how to send images into this system.

PaulHoule 6y ago
See https://hyper.is https://hyper.is You would think you could type $ cat image.png and the terminal would see the "89 50 4e 47 0d 0a 1a 0a" and display the image inline, but it doesn't really work because a tty can get junk characters in it from other processes and images would get corrupted from time to time. I would point to https://en.wikipedia.org/wiki/Midnight_Commander https://en.wikipedia.org/wiki/Midnight_Commander as something that adds some simple GUI to the CLI experience.

pjc50 6y ago

Attempts have been made over the years at adding graphical capability: https://stackoverflow.com/questions/2114347/raster-graphics-in-xterm https://stackoverflow.com/questions/2114347/raster-graphics-... You have a chicken egg problem; you need to get people to want to use both a different shell and a different terminal emulator, at the same time. Textual mode fits well with all the tools. You can't grep an image sensibly.

ttyprintk 6y ago

The other answers give cutting-edge workarounds. Historically, the ancestor of Linux was developed in an environment where terminal standardization usually stripped out the marketable graphics features. Sound was single beeps, vocalized with ^G. If it seems overdue to standardize a real-time character-encoded graphics protocol, you can look at the Tektronix 4104 and descendants. That being said, typesetting was important early in UNIX. Even though the interface was command-line, UNIX implemented roff and maybe wouldn’t have succeeded if it couldn’t word-process into roff. Word processing was the first application for UNIX outside of the Labs.

PaulHoule 6y ago
Worse than that "the terminal" was originally a 110 bps. "Rm" was short for "REMOVE" because it would drive you crazy to wait for the printer to thunk away 6 times. The Bell Labs Technical journals is full of user studies for little things they could do to make UNIX users more productive. Even by 1990 it was likely to be 9600 bps, maybe you had a faster network and portable graphics X windows at a university lab. In the 1980s the Bell Labs folks had a rip-off of the Xerox PARC system that was network portable in the 1980's (see "Plan 9") but it was strange custom hardware and software that never really caught on.

simonblack 6y ago

Just like emojis can't transmit all the subtle nuances that words can, a textual interface is much more nuanced than a graphic shell. In practical terms, a graphic shell can only give you what the shell's programmer has envisaged is possible, and has given you a menu to include those specific things. That can't cover every single imaginable eventuality. If you don't believe that, try making a menu on paper that covers everything possible that a textual shell can do.