On Fri, May 20, 2011 at 9:40 AM, Connor Lane Smith <c...@lubutu.com> wrote: > I suppose that could be a useful interface, so long as it was clear > which commands are associated with which output. Otherwise stdout > could get a little messy. Also, by default stdout and stderr ought to > be combined, perhaps with stderr in yellow or something.
I don't understand why. If you want stderr to be combined into stdout, suffix 2>&1 to your command. By default, I think different filehandles should land in different outputs. As for associating commands with their output, that would be trivial. Typing in your command script in the input window and causing it to be executed should start a subshell. Captured output from stdout should be rendered in the output window, perhaps with a box around it, possibly numbered. Then you can go back to the input window to browse your command history, and selecting a history entry should be able to bring up the output of that command. when you have a clean separation between filehandles, and you're not just dumping all three into one bidirectional window, maintaining the relationships between data in each should be much, much easier. This obviously ignores the problem of backgrounded tasks, but even that would be nicer: instead of just getting shit dumped on the screen with a pid prefix, the terminal could just open another output window. The more I think about this interface the more I want to write it. -- # Kurt H Maier
