Something to say about echo xxx >&2, and a better design for stderred

[revintec]

see this #16

I have some thoughts about this:
is it because that the Terminal GUI(whatever is responsible to display the data onto screen) uses the same FD as both stdout and stderr for the child/grandchild they launch.
GUI -> bash(stdout/stderr redirected to same file BEFORE process start) -> some program(inherit stdout/stderr from bash, which are redirected to the same file)

That's why in this case echo >&2 doesn't work.
Like you said, the ACTUAL FILE that receive the data is the same, so you can't distinguish it, and redirection happens AFTER writing, so you lose the first chance to catch the data.

I'm written terminals myself, here is why I thinks we HAVE TO use the same file for both stdout and stderr: if we use the different one, we can't properly display them to the screen.
Long version: say programA writes to stderr and then immediately writes to stdout, from the terminal's point of view, it sees that stdout and stderr both got some data, but it can't know which one is written first, so it can't display it properly(pipes doesn't contains timestamp for data flows, and IO are blocking so you have to use threads, so synchronization problems, and still can't get timestamp, non-blocking IO is the same, no guarantee of FIFO for events), this is THE PROBLEM.

I know how to solve this on windows(which I use before I bought this MACBook Pro), but I'm new to OSX programming, so I'm unable to come with actual OSX code(not yet) even I know how to solve the problem. It involves the following: multi-threading, with blocking IO and message passing, IO redirection.
Basic idea is:
recreate different FDs for stdout/stderr(done AFTER shell is launched) for shell progress, hook all children's write related functions, provide extra info to shell, shell got data, solves THE PROBLEM, do highlighting, then pipe THE ORIGINAL DATA back to the original FD shell have got when it starts.
And this way, solves this problem, any redirection or what, should work fine, and the highlight instructions(ESC[xxm) doesn't pollute the stderr, it's the perfect solution.

Hope to see this feature soon.

[cehoffman]

The solution you are proposing is already available using a tool like colorize which will colorize the stderr of the shell instead of hooking all commands. There are issues with this approach because of buffering in the write stream.