3 ms·

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

by 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
  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.
  - jstimpfle 10y ago
    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 :-)
    - CJefferson 10y ago
      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).
      - DSMan195276 10y ago
        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.

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
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.
- jstimpfle 10y ago
  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 :-)
  - CJefferson 10y ago
    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).
    - DSMan195276 10y ago
      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.