6 ms·

This isn't entirely relevant to the article, but I hope some shell/TTY expert might read this, and know the answer :) Hypothetically, could a TTY, in combinati

This isn't entirely relevant to the article, but I hope some shell/TTY expert might read this, and know the answer :) Hypothetically, could a TTY, in combination with the help of a shell, be able to separate the stdin, stdout and stderr of every running program? By default the shell could do what we normally see, but then easily (with some kind of GUI control) let me pull a particular program's stdout/stderr out to a seperate window, including (if I stored it) all it's previous output, and redraw the current terminal removing that program's output. I've always been tempted to do something like this, and I'm curious if there is any massive reasons it's simply not possible.

EdiX 10y ago
Are you trying to do mathematica notebooks for the shell? There's no easy way to do this, you have to run each command into a separate pseudo-tty. You can only do this with a combination of a special terminal emulator and a special shell that only runs inside the special terminal emulator. You can't do this and then just use bash.
- CJefferson 10y ago
  Oh, I know it would be a serious undertaking (I'd probably try hacking it into fish, because I've looked into it's code-base). I was just wondering if it's hypothetically possible, and why no-one has done it :)
  - EdiX 10y ago
    I don't know. The reason I haven't done it is because it's too much work, there is no pleasant way to do GUI programming and I don't have a clear design for how the UI.
- bitwize 10y ago
  You can do it with bash and tmux.
dsr_ 10y ago
Yes. http://tldp.org/LDP/abs/html/io-redirection.html http://tldp.org/LDP/abs/html/io-redirection.html shows how to do it in bash for any given process.
DSMan195276 10y ago
Generally speaking, not with current ttys. The main thing you're missing is some way to know what output is coming from what program. Keep in mind, some output is generated by the kernel and isn't from any programs at all, and output may come from more then one process at a time. The kernel is the stage where the 'mixing' happens, so if you wanted real support for this you'd want to modify the kernel in a way that lets the tty device get separate streams for each process. That said, the best way to try to achieve something similar to this is probably by having your program open a completely new tty device for every process-group you start. Then the GUI program can buffer the outputs from all of those tty devices and do the 'mixing' itself. It is important to use actual tty devices here so that `isatty` returns 1 for al of the children outputting to the tty. If you went for a purely software-based approach by simply using `pipe()`s the programs would know they're not outputting to a tty and would forgo things specific to tty's like coloring, and also either output warnings or simply not work at all. My other ideas are some abuse of a custom shell and `SIGTTOU` or `tee`, but I don't think you could get either of those things to work very well.
- jstimpfle 10y ago
  To add, separating program's streams would be completely against the Unix idea of making useful programs by combining smaller specialist programs (you implied that by mentioning process groups).
  - DSMan195276 10y ago
    I wouldn't really say that. The tty deals with process-groups, not single processes. The idea I gave would put process-groups into separate ttys, not split-up the groups themselves.
    - jstimpfle 10y ago
      Yes - I was agreeing with you but my comment was unclear. I wanted to make explicit what you implied by use of "Process groups".
  - CJefferson 10y ago
ksherlock 10y ago
Let's say you're an xterm, terminal.app, iTerm2.app, etc. You open a pseudo terminal which gives you a pair of file descriptors - a master and a slave. The parent process (xterm, et alia) does all reading/writing through the master file descriptor. The child process sets stdin, stdout, and stderr to the slave process and execs bash. So when bash starts, stdin, stdout, and stderr are the same file descriptor. And those descriptors (the child pseudo terminal) are inherited by any programs launched from bash. (bash can redirect stdin, stdout, and stderr of course) Backing up a step, xterm (et alia) could open 2 pseudo terminals and use one for stdin/stdout and the second for stderr. And then stderr could be displayed in a separate window, always blinking red, or whatever. (You could also use a pipe for stderr. It would slightly less compatible since it's a pipe and not a pseudo terminal. Somewhere, there's probably a piece of code that cares.)

EdiX 10y ago

Are you trying to do mathematica notebooks for the shell? There's no easy way to do this, you have to run each command into a separate pseudo-tty. You can only do this with a combination of a special terminal emulator and a special shell that only runs inside the special terminal emulator. You can't do this and then just use bash.

CJefferson 10y ago
Oh, I know it would be a serious undertaking (I'd probably try hacking it into fish, because I've looked into it's code-base). I was just wondering if it's hypothetically possible, and why no-one has done it :)
- EdiX 10y ago
  I don't know. The reason I haven't done it is because it's too much work, there is no pleasant way to do GUI programming and I don't have a clear design for how the UI.
bitwize 10y ago
You can do it with bash and tmux.

dsr_ 10y ago

Yes. http://tldp.org/LDP/abs/html/io-redirection.html http://tldp.org/LDP/abs/html/io-redirection.html shows how to do it in bash for any given process.

DSMan195276 10y ago

Generally speaking, not with current ttys. The main thing you're missing is some way to know what output is coming from what program. Keep in mind, some output is generated by the kernel and isn't from any programs at all, and output may come from more then one process at a time. The kernel is the stage where the 'mixing' happens, so if you wanted real support for this you'd want to modify the kernel in a way that lets the tty device get separate streams for each process. That said, the best way to try to achieve something similar to this is probably by having your program open a completely new tty device for every process-group you start. Then the GUI program can buffer the outputs from all of those tty devices and do the 'mixing' itself. It is important to use actual tty devices here so that `isatty` returns 1 for al of the children outputting to the tty. If you went for a purely software-based approach by simply using `pipe()`s the programs would know they're not outputting to a tty and would forgo things specific to tty's like coloring, and also either output warnings or simply not work at all. My other ideas are some abuse of a custom shell and `SIGTTOU` or `tee`, but I don't think you could get either of those things to work very well.

jstimpfle 10y ago
To add, separating program's streams would be completely against the Unix idea of making useful programs by combining smaller specialist programs (you implied that by mentioning process groups).
- DSMan195276 10y ago
  I wouldn't really say that. The tty deals with process-groups, not single processes. The idea I gave would put process-groups into separate ttys, not split-up the groups themselves.
  - jstimpfle 10y ago
    Yes - I was agreeing with you but my comment was unclear. I wanted to make explicit what you implied by use of "Process groups".
- CJefferson 10y ago

ksherlock 10y ago

Let's say you're an xterm, terminal.app, iTerm2.app, etc. You open a pseudo terminal which gives you a pair of file descriptors - a master and a slave. The parent process (xterm, et alia) does all reading/writing through the master file descriptor. The child process sets stdin, stdout, and stderr to the slave process and execs bash. So when bash starts, stdin, stdout, and stderr are the same file descriptor. And those descriptors (the child pseudo terminal) are inherited by any programs launched from bash. (bash can redirect stdin, stdout, and stderr of course) Backing up a step, xterm (et alia) could open 2 pseudo terminals and use one for stdin/stdout and the second for stderr. And then stderr could be displayed in a separate window, always blinking red, or whatever. (You could also use a pipe for stderr. It would slightly less compatible since it's a pipe and not a pseudo terminal. Somewhere, there's probably a piece of code that cares.)