VOTE: Redirecting stderr to the tty?

[Ole Tange]

On Sat, Dec 13, 2014 at 9:39 AM, Ole Tange <ole@tange.dk> wrote:
> On Fri, Dec 12, 2014 at 3:44 PM, xmoon 2000 <xmoon2000@googlemail.com> wrote:

>> What is the best method for me to capture all errors from my scripts to a
>> single file?
>
> 3 options:
>
> Stop using --eta.
> Use --joblog (if all you need is the exit value)
> Use --results (if you really need the whole stderr)

Inspired by this problem I wondered how you could work around that.
http://unix.stackexchange.com/questions/174055/controlling-the-terminal-while-in-the-middle-of-a-pipe/174058#174058
pointed to the idea of finding parent pid and use the stderr or stdout
of that. If running in a terminal it will typically do the right
thing.

I now have a prototype that works on all platforms that support `lsof`.

So my question to you, dear users, is now whether this should be
default? Should GNU Parallel's status/error messages be sent to the
parent pid's stderr instead of the current stderr?

Here are my considerations:

For most situations it will not matter at all: stderr is the terminal
for both job output and for status message:

   parallel my_prg ::: 1 2 3 >my_prg.out

For xmoon's situation it does make a difference. He will be able to do:

   parallel my_prg ::: 1 2 3 >my_prg.out 2>my_prg.err

and be sure that there are no status messages from GNU Parallel mixed
into my_prg.err. The status messages will be sent to parent pid's
stderr which in this case will be the terminal.

A problem I see is that you cannot redirect GNU Parallel's status
messages: They will go to the terminal unless you do something like:

    bash -c 'parallel my_prg ::: 1 2 3 >my_prg.out 2>my_prg.err' 2>parallel.msg

This may lead to confusion when you get a different behaviour when
running interactively in a terminal or run via a cron script. So this
may conflict with Principle of Least Astonishment.

What do you think?


/Ole