Hacker News Reader

Comment by CJefferson | Hacker News Reader

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.

View on HN

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.

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).

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.

Yes - I was agreeing with you but my comment was unclear. I wanted to make explicit what you implied by use of "Process groups".

I'm not suggesting changing that -- just that when all those programs eventually output, the shell/TTY store each program's output in a separate stream, rather than just multiplex them all together in a giant pile.

The TTY is just a user-facing device and as such has a single read-write pair.

    - You can read() from it (this is basically what the user types into the keyboard)
    - You can write() to it (this gets translated into what is displayed on the screen)

The TTY has no business separating programs. It doesn't know or care what its input/output is connected to.

What you are looking for is shell redirection.

If you have a problem with redirection in a concrete shell script, get in touch - I can fix it for you :-)

I about shell redirection, but sometimes I get annoyed by things like:

* I am running a program, decide to 'ctrl+z, bg' it, but it keeps spewing onto my terminal. Instead, just store it so I can look at later

* I want to say "take the output of the previous program and put it into a file", without either running it again, or cutting + pasting it into a file.

Nothing serious, I just feel there is "something better" (although it would be a serious change).

Personally I would agree with you. If you don't want to go a hacky route it would require some redesigning, but there's no real reason graphical terminals have to keep acting like a dumb terminals when stuff like what you described is easily achievable.

The best approach would probably be to make parts of the tty framework implementable outside of the kernel. If you could do that, then you could skip the kernel completely and do all the redirection and such directly from the graphical terminal by making it essentially implement it's own tty framework. Getting what you want would be very easy at that point, because you'd have direct access to the inputs and outputs to all of the various processes and process-groups. So it would just be a matter of keeping them all in separate buffers and keeping track of what you're displaying in various outputs.

> I am running a program, decide to 'ctrl+z, bg' it, but it keeps spewing onto my terminal. Instead, just store it so I can look at later

This exists. It's called "less".

It's not the program which keeps spewing at your terminal. At the point where you Ctrl+z the program has already written the content that keeps being spewn. It's just that the terminal is too slow to display the data in the buffer.

> I want to say "take the output of the previous program and put it into a file", without either running it again, or cutting + pasting it into a file.

I want to do that sometimes, too. And then I just re-run it.

It's not a problem of the implementation, I just didn't run it right the first time.

Shells could be implemented to remember the output of your last command-line. There are some questions though: Where should the output be stored (memory / disk usage), what about very big or infinite streams, what about interactive applications... "less" is such a program it makes a particular set of decisions wrt to these questions.

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.)

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.

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 :)

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.

You can do it with bash and tmux.

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

Reply on news.ycombinator.com