Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr

[Jim Meyering]

Bruno Haible wrote:
>> They make it so with "set -x", environment settings
>> appear in stderr output.  For example, this command:
>>     /bin/sh -c 'set -x; P=1 true 2> err' 2>/dev/null; cat err
>> prints "P=1" on those two systems:
>
> This test disqualifies also 'ksh', which is considered the "good"
> shell on Solaris, AIX, and a number of other systems:
>
>     I executed the command
>        (set -x; P=1 true > inner-out 2> inner-err) > outer-out 2> outer-err
>     with a number of shells. Results: inner-out and outer-out were always
>     empty, and
>
>                          | inner-err      | outer-err                    |
>     ---------------------+----------------+------------------------------+
>     Solaris 10 /bin/sh   | P=1            | + true                       |
>     ---------------------+----------------+------------------------------+
>     ksh-93s              | + P=1          | + true                       |
>     Solaris 10 /bin/ksh  |                | + 1> inner-out 2> inner-err  |
>     ---------------------+----------------+------------------------------+
>     bash 3.2.39          |                | + P=1                        |
>                          |                | + true                       |
>     ---------------------+----------------+------------------------------+
>     dash                 |                | + P=1 true                   |
>     ---------------------+----------------+------------------------------+
>     zsh 4.3.6            |                | +zsh:3> P=1 +zsh:3> true     |
>     ---------------------+----------------+------------------------------+
>
>> the result will be that each init.sh-using test
>> will be skipped.

Thanks for the summary.

> I don't find this a good result.
>
> Observe this:
> - Looking at the stderr output of some programs started with environment
>   variables happens in some tests, but is not very frequent.

But like gcc's -g (-g must not change semantics),
I don't want turning on shell debugging (set -x) to make my tests fail.
Ever.

> - When you analyze the stderr output of programs, you need to filter out
>   all lines that start with '==' also, because these are the marks emitted
>   by valgrind.

valgrind?  Not an issue, since. you can/should invoke valgrind
in a way so that it doesn't pollute stderr.

> - When you are at it, you can also filter out all lines that start with
>   '+'.
> - The only remaining problematic shell is then Solaris 10 /bin/sh,
>   which is already disqualified by
>      test $(echo y) = y
>
> So, instead of skipping all init.sh based tests on some platforms, I would
> propose
>   - either to skip only if 'set -x' is enabled; this can be tested by
>     test -z "$( (P=1 true 2>&1) 2> /dev/null)"
>   - or to handle this problem in each test that analyzes the stderr output
>     of some program.

Even if the triggering condition is not common, it's
not easy to mechanize something to protect us from it,
so I prefer to avoid losing shells when possible.

I've pushed an improved patch.