This was a great write-up, especially if you like your ol' unix history. Aside: I love the stack exchange sites (i.e. stack overflow, etc) - they are probably one of my top companies based just on how much I interact with their sites.
"""So when you look to a "text window" on you linux system (under X11) you are looking to: a terminal emulator, connected to a virtual terminal, identified by a tty file, inside which runs a shell."""
Can anyone tell me why I can't zoom or select the text on this site on my iPad? Isn't this the very sort of thing we hate in flash thoughtfully recreated in HTML5?
Terminal is a program of some kind, like xterm, (or a monochrome device with nice smooth scrolling), shell is a different kind of program, that interpret your input like bash. TTY is an interface to access a system over serial line, and console is an interface pre-configured for administrative access. ^_^
A terminal is a physical device for access to a computer. The VT-100 and Teletype ADM-33 are both examples. Xterm is a terminal emulator for X--it pretends to be something like a VT-220, so you can run your text mode programs.
TTY, of course, stands for Teletype, which was a common terminal used in the early days of Unix. In the old days, you'd talk about having a whole room full of TTYs. Now, it seems to refer to the emulated terminals provided by a Unix-like system.
A console would originally be a specific terminal (often hard-copy, like a Teletype) hooked directly to the computer for administrative tasks.
You are correct. If you look at the bottom of posters/flyers for government services (suicide help lines, schedule services for transit, that sort of thing), you'll often see underneath "phone: " a line "TTY: " with a slightly different phonenumber following.
A terminal can also be a hardware device with a keyboard and monitor that is hooked up to a computer through a serial port. I used to have a VT102 hooked up to my Linux system at one point (it's in storage now).
If people just made sure to use the correct vocabulary, the issue would be a non-issue. I doubt there is a single person out there that 1) might encounter a terminal emulator, and 2) doesn't get that a VT102 actually existed from the name terminal emulator.
You have laymen with emulators on their telephones. It shouldn't be a hard concept to teach.
This should be taught in the first CS class at every school. It continues to stun me how many CS grads in the US don't understand the difference between these things.
Why should they know the difference between these things? Unless they are trying to implement a new terminal, there isn't much of a reason to know this minutiae. The rationale for the differences between them are mainly historical and not really a good design.
Now, I'm all for a "History of Computing" class being required for CS, but that's another story. I also wish that I had time during undergrad for a "History of Biology/Chemistry/science/alchemy" class (I was a biochem major).
They should know what they are because they use them every day. It's like a racecar driver not knowing the difference between an axle and a wheel, he doesn't have to know how to make them or even fix them, but he should damn well know what they're called. Understanding this issue is fundamental to understanding Unix, and is also a superb way of introducing some classical IPC methods. Last I checked most schools still devote a required class or two to the subjects but somehow it fails to work a good deal of the time.
"The rationale for the differences between them are mainly historical and not really a good design."
The separation of shell, a terminal emulator, and a psuedo-terminal is bad design? Really? I would love to see a rationalization for that. EDIT: Or downvotes will work fine as well I suppose.
Your "system as a whole" is the linux TTY... so exactly not the system as a whole. Furthermore, Alan Cox stepping down 2 years ago does not mean the linux tty system is unmaintained. It is in fact.
The reasons ttys and ptys are in kernel space are numerous. As one example, it needs to be there because different line disciplines are necessary and relying on a userspace program to implement them will not do. Ever notice how su/sudo/passwd/etc don't echo your password? Yeah, that sort of important. Furthermore, ttys in modern systems are tied to job control rather deeply. Implementing correct signal sending, sessions with controlling terminals, forground/background processes, etc in userspace? Have fun.
I could write a book on this subject, but this is easier: "Write a fully functional pty in userspace. If you ever manage to get that far, then compare your work with traditional implementations and defend it."
PS: ptys are not "emulating" anything in any meaningful sense of the word.
Userspace can not echo a password too, its not exactly difficult. And do we really need the job control model as is? If you started from scratch would you design it anything like this at all? And signals, it is all the least successful parts of the unix design...
If you are implementing all of your line disciplines in userspace 1) userspace where? 2) How do you handle other modes, besides just noecho? 3) How do you do that while minimizing responsibilities of user generated code?
"And do we really need the job control model as is?"
If someone is discussing the concepts with the wrong vocabulary, then that means they are sufficiently important to that person that the should have known about it.
I wouldn't be noticing that many people don't understand the concepts if it were not relevant to these people. It's not like these are particularly deep subjects either, people directly interact with 2 of the 3 every day. They're not buried details, they're frontline human-computer interfaces.
P.S. Understanding cars is very similar to understanding computers. There are numerous layers of abstraction in place that allow us to rope off areas of understanding for later. I would argue that there is actually more information to learn about cars than there is computers for a few reasons: 1) cars are jam packed full of computers these days. 2) there are half a dozen engineering and science disciplines involved in cars off the top of my head, and that number is only limited by the number I know the name of. 3) (depending on if we're pulling in computing hardware into the discussion or not..) cars are things built in the real world with imperfect knowledge of all the systems that go into them. You can be sure people a century ago were not paying a ton of attention to fluid dynamics in engine cylinders. You can always dig deeper into what is actually going on.
My point is here is that if computers are more complicated than cars, it's not by much. I believe my comparison holds.
Each time you have to answer "why does Ctrl-Left go back a word on my laptop, but when I ssh into my server, it just prints some weird characters?", it's useful to know the distinctions between terminals and shells.
That just sounds like a broken implementation of readline or some such. When I ssh, everything works fine.
Anyway, the distinction is only important in very narrow cases. I've heard people say "Open a new terminal", "Open a new command window", "Open a new shell", and "Open a new console". They mean the same thing in this context. The contexts where they don't and where that fact needs to be spelled out don't come up very often. This unwarranted attention to detail is analogous to changing a flat tire with a friend by saying: "Hey, grab the spare wheel out of the trunk" vs. "Hey, grab the spare tire out of the trunk". This whole thread is like seeing that there are technical differences between a wheel and a tire in the context of a repair shop, but in the context of "get me the circular thing from the trunk that I can attach to my damn car to make it go again" they're the same, and then complaining when people use the second context and don't keep the terms distinct.
It's not a broken implementation of readline, it's either a failure to use readline or improperly set terminfo. TTYs in canonical mode will support backspacing, but not moving around inside text. "Ctrl-Left go back a word on my laptop, but when I ssh into my server, it just prints some weird characters?" reaks of straight up canonical mode.
And say you had this problem, guess what is not going to work? "I have a problem with my command window", "I have a problem with my console", "I have a problem with my TTY".
ouch, the downvotes! for posterity let me note here that, in fact, I really did have to clean vt220 keyboards with alchohol wipes every week when working in the comp. lab. I have very fond memories of the vt220 despite this ignoble responsibility. Not germane enough to the conversation but anyone that spent time on a real terminal will hopefully relate.
