A Guide to the Terminal, Console, and Shell
thevaluable.dev
thevaluable.dev
I am not sure I do now (specifically how SSH ties in to this).
But at least I now know more about terminals, shells, rawmode and ptms/ptx and more.
This link right here fits right in with the following ones:
[0] https://biriukov.dev/docs/fd-pipe-session-terminal/4-termina...
While the overall focus of the book is on programming with Notcurses[2], the author shares a wealth of related info and history throughout its pages. Note also that Notcurses has evolved quite a bit, but the book is still a nice resource.
Check out his youtube channel it's a wild ride! Good example video from it. https://www.youtube.com/watch?v=fq963c6Fl5E
(I know it sounds like I could be Nick with all this praise but I'm just a guy that appreciates people with interesting obsessions that may benefit me some day).
Boy, what did I just see—and especially hear?!
But never mind.
Still the main question remains regarding this kind of TUI stuff: Why?
I see that it's a impressive demo and great hack, sure. But why should we use a glorified virtual line-printer to display all those things? It's just layers of craziness (like I started to call such stuff).
In the end our hardware will render pixels! (In big contrast to the original hardware for which this stuff was invented in the first place.)
Misusing our glorified virtual line-printers should be finally replaced with something that acknowledges our current reality (which is: HW based on pixel framebuffers) instead of fighting this reality. It's a complete joke that I need a multi-GHz computer and an expensive GPU with many TFLOPs only to be able to scroll somehow "smooth" in an UI form the 60's…
A local PC or phone may be your only experience but it is far from the current reality in computers. most computers these days are embedded devices or remote servers, neither of which have pixel framebuffers, or even "video displays". Heck, even inside your PC are computers that only have serial connections: I once had a flaky consumer-grade hard drive that required me to hook up a serial line to its control console from time to time and issue text commands to clear its error buffer (not buying a Seagate ever again).
In the end our hardware gets its input from sensors, operates actuators, and performs arithmetic transformations from its input to its output. A very few of those actuators result in coloured blobs on a large LED matrix. Don't get confused with that as a single universal use of computers.
Even the interaction with your HDD through its serial interface ended up on, no big surprise, your display.
I don't question TUIs as such!
I question how we implement them.
The whole "terminal emulator dance" is imho strictly unnecessary.
You could also talk to your HDD through its line interface by, for example, some proper RPC mechanism. (With the help of some adequate client software, which could be a CLI application, but also a GUI tool). The HDD doesn't have to provide a framebuffer based user interface, of course. Your client does.
Someone else pointed even already to something baking my assumption that getting rid of all the layers of emulation of more than ancient hardware would be not only possible but is even desirable:
Some things that poked me while reading: * varying use of “encrypt” and “encode” for transmitting data; suggest sticking with encode/decode * mention of Intel x87 when I think you probably meant x86
> It’s estimated that, at its pick, in 1929,
*peak
Yeah, my bad. I'm not a native English speaker, and somehow to me the word "encoding" was only used for encoding information on a computer. I was confused when I wanted to say the same thing for telegrams; I began to use "codify", and then "encrypt", which is obviously wrong.
I fixed the mistake. Sorry for that.
Do some projects in this direction even exist? Or are we going to stick around with abstractions of things even most people's grant great parents haven't ever seen because this tech was already long obsolete at their time?
Thanks for the links!
This looks like the future.
It does everything 100% correctly.
(Now "only" the rusty Unix commands need to get evolved into some proper interactive language and this would be the perfect CLI.)
I'm impressed heavily. Going to install this ASAP to play around with it.
We should get rid of all the historic accidents. Really.
Imho it's completely crazy how computers "work" today.
Modern computers still need to emulate "a PDP-7" because that's the only kind of machine C runs on fast.
But the sequential command stream machine (which is the abstract machine of C) is extremely inefficient. It's a mayor pain to extract parallelism from an inherently sequential command stream! We built crazy shit like "hardware JIT compilers", that are embedded nowadays in all CPUs, only so the CPU can maintain the PDP-7 illusion to the outside world (which is, in the end, still C, and nothing else) even it's a proper data-flow machine internally.
But because all the SW world is build in C (or languages that work the same) nobody invests in alternative architectures. Because C would not run fast on such machines, and they would fail in the market if you would need to rebuild the whole SW world first to get any advantage.
C (and, tragicomicaly its portability) was a trap!
And we will die a painful death even before anybody would start to think to finally remove the von Neumann bottleneck (which is inherent to sequential command stream machines with RAM).
I for my part would love if someone would invest in something like a modern take on the Connection Machine, but build form the ground up with a HW-SW co-design approach. (Of course this would be some work; you would need to build the hardware, which is comparably easy, but also some adequate programming language and ecosystem, up to a completely new designed operating system, and convince people to "rewrite the world" for your new system — which is the hard part).
> from the ground up (bits and bytes)
In this context it should read "(trits and 'trytes')" (only that we would maybe need a new world as trytes are historically six trits, but would be better 9 trits; so we could directly use a septemvigesimal system, which maps excellently to the English alphabet + "point"), and it should be of course balanced.
Time to finally switch to the most efficient information encoding, when we're at it! (Binary was also just an historic accident, chosen because it was most easy implemented on the ancient integrated circuits).
The use of C as a scapegoat is odd. What alternatives would have led to a different world of processors? Pascal? PL/I? Experiments in parallelism at the time like Erlang are about process-level parallelism, not the kind of instruction-level parallelism this line of argument calls for.
You absolutely can have simpler systems than we use today, but let's not fool ourselves about how we got here.
That's not a "cliche". It's the reality how computers work today.
Internally they're data-flow machines since quite some time. But they need to emulate a command stream machine (which did not change fundamentally since the time of the PDP-7!) to the outside world.
> Explicit instruction-level parallelism has its own issues that make it difficult to use effectively, precisely because it must do statically what out-of-order processors do dynamically.
That's why nobody here ever talked about "explicit instruction-level parallelism"…
> The use of C as a scapegoat is odd.
No it isn't, as the success of C is the root of all evil in this case.
> What alternatives would have led to a different world of processors? Pascal? PL/I?
No, of course not. Because Pascal or PL/I are of course also "just C" (with some minor, and regarding this consideration here, completely irrelevant differences).
> Experiments in parallelism at the time […]
Are irrelevant.
The topic is: How would things look like if we would start over with all what we know now, and with our current technical capabilities.
> the kind of instruction-level parallelism this line of argument calls for.
At least I have talked explicitly about data-flow (and nothing else)!
Imho the whole command stream based approach is a dead end.
Dynamically reconfigurable data-flow hardware (with local scratch memory instead of RAM) is imho the answer.
But of course it's almost impossible to compile sequential command streams (aka. "imperative programs", which is synonym to C and all languages that work the same, so actually almost all languages in existence) into anything that could be efficiently executed on such data-flow hardware. That's why you would need to "rewrite the world" form scratch to get any benefits from finally sane hardware (instead of the expected degradation in case you would try to map our current sequential command streams into this new world).
Too bad it was so unstable I stopped using it. Should maybe give Enlightenment another try in the coming year.
https://saitoha.github.io/libsixel/
But that's just another "layer of craziness", imho. (Even it's quite cool).
I think the whole terminal should be replaced. Not even with something funky. Just a proper RPC + streaming protocol based on some sane modern tech. (No, no HTTP! Simple and lightweight. Tailor made for the task. So it works also in an embedded setting; and lasts for the next 50 years :-)). Of course it should also have separate control and data channels. (That's a mayor flaw of the "classical" terminal tech. The in-band transport of control is a big PITA, and can be even an security risk).
And if they don't, https://github.com/csdvrx/sixel-tmux will give you the best rendering it can do
“imgcat filename.jpg” for example will display the image in your shell/terminal.
I find that most people who don't use terminals don't do it out of pure preference for GUIs over CLIs. Instead, they use GUIs because they simply don't want to spend time learning how to use CLIs.
If they did, I bet 90% of people would move over.
It both is and isn't "a whole language". Most commands just execute a single program with options and/or arguments, except you don't have the overhead of opening a GUI, finding the right dropdown menu, etc. You quickly start to pick it up like you would a spoken language, remembering the "words" for actions, and it becomes a very natural way to think.
IMO the biggest stumbling block is just learning how to type efficiently. This includes knowing about tab completion, history search, putting stuff in your .bashrc and so on.
Did anyone ever find a good way to use these in the terminal ?
My shell library uses them to pass portable data around in groups of records, to parse and modify portable filenames, to construct shell commands and scripts automatically and to prepare plaintext data chunks for binary encoding and processing.
I don't know of plaintext editors making use of the separators by default, because they are not considered plain-text in the POSIX sense (although this leads to some tedious semantic debates that I am profoundly disinterested in).
Edit: LF, not CR, but its not universally like that.
These correspond to the it primarily being a printer with control codes, with keyboards, tape punches and tape readers being additional (in various incarnations of the larger Teletype device family).
The codings are distinct to enable overstrike and faster "next line w/out return" mechanical performance.
[1] https://en.wikipedia.org/wiki/Teletype_Model_33
[2] https://en.wikipedia.org/wiki/File:Mappa_Teletype_ASR-33.jpg
I whine (flyback transformer) and I shimmer (unstable tube needs a degauss) and I am slow (-really not reliable at 115200 if even capable, which I doubt. I last ran it 9600 attached to a sun workstation serial console) and best of all my keyboard is basically the same as that asr33 and really, really tiresome to use.
They're mostly better in memory than in real life. The vt100 and subsequent weren't bad, good enough for people like systime in leeds to clone them (they got done for cloning Vax boards, and selling them behind the iron curtain. The factory is a secret spy headquarters in the original "edge of darkness" TV series) and sell cheaper. The vt240 was pretty good. The blit and subsequent were lovely, but had a brief life as real graphics workstations came up. Really, the depraz mouse made the blit/gnot/jerq worthwhile. The first time I met a terminal device which was not 80x24 was a blit class terminal in ucl-cs.
On an ICL (ok. 3 rivers. ICL made it under licence in musselburgh south of edinburgh) Perq I used before then you used a terminal(ish) entry which may also have been not 80x24. The vertically mounted hard disk had a translucent cover and you could see static type sparks coming off the drive hub. really bizarre. It used display memory to compile so your text input window corrupted as you compiled. stty reset/clear fixed it.
Having multiple vty on the various BSD on Intel was nice. Vty4 was like steering, behind the scenes or something during the installer, and they launched a debug shell on one.
You learned to use stty a lot on old lines. Some were half duplex and some worked like bad antenna at high baudrate and picked up phantom presses in the 50 pair bundle.
ASR-33 was upper-case only hence Getty on BSD detecting upper-case only at login and v7 working UC and vi having an UC mode. It got removed from FreeBSD in the 90s.
My memory is the xterm implements the ANSI terminal escape codes which are pretty much vt100 because DEC either informed the standards committee decision with a pre implementation or implemented the standard, and MIT had lots of vtxxx series and so used the same to write the escape codes on X so Emacs and vi came along for the ride easily in termcap.
I'm not a native speaker. It doesn't excuse my mistake though.
I feel like this article has been written better before, e.g. in the article's own sources.
So the article begins with a story where a character, who doesn't know what he's talking about, try to mentor one of his colleague. It might be awkward though, and difficult to understand; sorry for that.
For sure this article was written better by others, but to me they were also lacking some stuff. I never found an article summarizing the whole story; most of the other sources were brushing away too much information for me to understand really why the TTY device had this weird structure.
But I guess not everybody will agree... and that's fine :)
For your next issue, I would suggest talking about pictures in terminals: from the historical sixel to the custom formats like kitty, and maybe connecting them with sixel-tmux
Actually, terminal session managers like screen and tmux would be worth another
It’s a 7 bits codes, allowing to send bigger messages than with the Baudot (or the Murray) code, even including the luxe of lowercase and uppercase letters.
I think "luxe" is really "luxury"?
No, tty(1) prints the name of the terminal connected to stdin. This is not necessarily the same as the controlling terminal.
> who - Show all the users logged in a controlling terminal
This is confused too.
So, do you know what's the difference between the "controlling termina" and the "terminal connected to stdin"? I though the terminal connected to stdin was the controlling terminal...
$ tty
/dev/pts/1
$ tty < /dev/null
not a tty
$ ps -q $$ -o tty= < /dev/null
pts/1
$ sh -c 'pid=$$; tty=$(ps -q $pid -o tty=); echo "$tty" > /dev/tty' <&- >&- 2>&-
pts/1Can someone enlighten me please?
(Also, what do you mean "casually states"? There's a long section detailing the history of the terminal right in the article, am I misunderstanding your question?)
"TODO: Add a screenshot of the login screen!"
in the article. Thanks for it, it was really interesting btw.