On Fri, May 20, 2011 at 9:40 AM, Connor Lane Smith <cls_AT_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 MaierReceived on Fri May 20 2011 - 15:54:41 CEST
This archive was generated by hypermail 2.2.0 : Fri May 20 2011 - 16:00:08 CEST