5 ms·

Would you agree that the whole TTY subsystem makes very little sense in this day and age? Why not let programs operate in raw mode by default and provide user-l

Would you agree that the whole TTY subsystem makes very little sense in this day and age? Why not let programs operate in raw mode by default and provide user-level library calls for input line buffering?

jstimpfle 8y ago
It's important for job control. Like Ctrl+c or Ctrl+z.
- JoshTriplett 8y ago
  Arguably the shell or terminal could handle those.
  - jstimpfle 8y ago
    I don't know. It is one of the recurring questions in software development (or politics...) what should be centralised and what should be distributed. Job control might be one thing that we need a good default for anyway, so why not implement it in a central place?
- jml7c5 8y ago
  Why not do that screen/tmux style, where shell takes input and passes it to foreground program, unless it's one of those special key sequences?
  - jstimpfle 8y ago
    That's not what happens with screen or tmux (or xterm, or sshd on the remote side of an ssh connection...). These allocate a pseudo terminal (PTY; which is a structure in the kernel) and connect to the master end. Using that they emulate a terminal, which has a virtual keyboard and a virtual screen. A shell (or another program) is started, with its input and output(s) connected to the slave end. The virtual keyboard might be X11 key events in the case of xterm, or a network stream in the case of sshd, or simply the stdin downstream from another terminal in the case of tmux. That keyboard character stream is fed into the write fd of the master end of the PTY. The virtual display is implemented by processing data read from the read fd of the master end of the PTY. That might involve drawing to an X11 window in the case of xterm, or sending back data over the network in the case of sshd, or writing to stdout connected to another terminal in the case of tmux. The important part is this: The job control is still done in the kernel as part of the PTY implementation. That implementation is where for example a Ctrl+c (0x03 byte) is converted to a SIGINT which is then sent to the slave program.
thatcks 8y ago
Raw mode by itself is essentially useless for almost all programs; in order to do anything with it, you already need an entire surrounding collection of code to handle editing (even basic things like backspacing) and so on. But line-oriented input remains useful on its own without additional user-level code, again precisely because of the editing support the kernel already provides for you. Since you already need user level code to make any real use of raw mode, the user level code can also set things into (and out of) raw mode as you need it, so line mode remains a sensible default. If anything things should move the other way, with the kernel providing more readline-style line editing in 'line mode' so that programs need to implement less of it themselves. But this would provoke all sorts of arguments over what line editing the kernel should support and so on, and then someday someone will suggest that the kernel should let you implement your own in-kernel line editing using eBPF (or WASM, if one leans that way), so people could push their preferred choice into the kernel when they log in or start up a shell on a new pty. (I'm the author of the linked-to entry.)
- JdeBP 8y ago
  You are Kenneth Almquist, and I claim my five pounds. * https://groups.google.com/forum/#!msg/comp.sources.unix/Vejydu91qCs/lYXJg2jSxdcJ https://groups.google.com/forum/#!msg/comp.sources.unix/Vejy...
  - thatcks 8y ago
    Funny you should mention that: ; ls -l <archives path elided> -rwxr-xr-x. 1 cks man 65536 Dec 4 1991 ./bin/bin.ultrix-mips/atty I see that GIDs around here have drifted a bit over the years.

jstimpfle 8y ago

It's important for job control. Like Ctrl+c or Ctrl+z.

JoshTriplett 8y ago
Arguably the shell or terminal could handle those.
- jstimpfle 8y ago
  I don't know. It is one of the recurring questions in software development (or politics...) what should be centralised and what should be distributed. Job control might be one thing that we need a good default for anyway, so why not implement it in a central place?
jml7c5 8y ago
Why not do that screen/tmux style, where shell takes input and passes it to foreground program, unless it's one of those special key sequences?
- jstimpfle 8y ago
  That's not what happens with screen or tmux (or xterm, or sshd on the remote side of an ssh connection...). These allocate a pseudo terminal (PTY; which is a structure in the kernel) and connect to the master end. Using that they emulate a terminal, which has a virtual keyboard and a virtual screen. A shell (or another program) is started, with its input and output(s) connected to the slave end. The virtual keyboard might be X11 key events in the case of xterm, or a network stream in the case of sshd, or simply the stdin downstream from another terminal in the case of tmux. That keyboard character stream is fed into the write fd of the master end of the PTY. The virtual display is implemented by processing data read from the read fd of the master end of the PTY. That might involve drawing to an X11 window in the case of xterm, or sending back data over the network in the case of sshd, or writing to stdout connected to another terminal in the case of tmux. The important part is this: The job control is still done in the kernel as part of the PTY implementation. That implementation is where for example a Ctrl+c (0x03 byte) is converted to a SIGINT which is then sent to the slave program.

thatcks 8y ago

Raw mode by itself is essentially useless for almost all programs; in order to do anything with it, you already need an entire surrounding collection of code to handle editing (even basic things like backspacing) and so on. But line-oriented input remains useful on its own without additional user-level code, again precisely because of the editing support the kernel already provides for you. Since you already need user level code to make any real use of raw mode, the user level code can also set things into (and out of) raw mode as you need it, so line mode remains a sensible default. If anything things should move the other way, with the kernel providing more readline-style line editing in 'line mode' so that programs need to implement less of it themselves. But this would provoke all sorts of arguments over what line editing the kernel should support and so on, and then someday someone will suggest that the kernel should let you implement your own in-kernel line editing using eBPF (or WASM, if one leans that way), so people could push their preferred choice into the kernel when they log in or start up a shell on a new pty. (I'm the author of the linked-to entry.)

JdeBP 8y ago
You are Kenneth Almquist, and I claim my five pounds. * https://groups.google.com/forum/#!msg/comp.sources.unix/Vejydu91qCs/lYXJg2jSxdcJ https://groups.google.com/forum/#!msg/comp.sources.unix/Vejy...
- thatcks 8y ago
  Funny you should mention that: ; ls -l <archives path elided> -rwxr-xr-x. 1 cks man 65536 Dec 4 1991 ./bin/bin.ultrix-mips/atty I see that GIDs around here have drifted a bit over the years.