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.
