This is a bit tricky. I don’t quite like how BASH_XTRACEFD works.

I personally like the idea to dup stderr at the time of
running “set -x” the best (any subsequent “set +x” will
close the dup; any subsequent “set -x” will close the
dup if open, then dup whatever stderr currently is anew).

However, none of these scenarios work well with subshells.
We could do something environment-y to pass the fd number
of the dup down to the subshell, but that’s get funny to
decide who dups or closes what when. Consider:

parentshell: FOO_DUPFD=25 mksh subshell

subshell: exec 25>foo; set -x

This would either mean that the shell has to dup FOO_DUPFD
upon startup if it’s set, or trace all redirections (which
we could use to avoid the dup in the first place… except
if stderr was actually closed…), or that the set -x in the
subshell would go to the file foo instead of to what the
parent’s goes.

Considering all this, and that XTRACE is not inherited by
subshells anyway (just sub-environments in the same shell),
I’d say ignore the fact and just dup on “set -x”?

Does anyone else have any ideas/comments on this?

-- 
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1179287

Title:
  un-nice things in “set -x”

Status in The MirBSD Korn Shell:
  New

Bug description:
  One:

  tg@blau:~ $ mksh-R41c -xc $'cat <<"EOF"\nfoo\nEOF\n'                          
                                  
  + cat
  + <<"EOF"
  foo
  tg@blau:~ $ mksh -xc $'cat <<"EOF"\nfoo\nEOF\n'                               
                                  
  + <<"EOF"cat
  foo

  Problem: no whitespace after here document marker.

  
  Two:

  tg@blau:~ $ mksh -xc 'foo=$(bash --version 2>&1 | head -1); echo "=$foo="'
  + + head -1
  + foo='+ + 2>&1 bash --version' 
  + echo '=+ + 2>&1 bash --version='
  =+ + 2>&1 bash --version=
  tg@blau:~ $ mksh-R41c -xc 'foo=$(bash --version 2>&1 | head -1); echo 
"=$foo="'                                 
  + bash --version
  + head -1
  + 2>&1 
  + foo=GNU bash, version 2.05b.0(1)-release (i386-ecce-mirbsd10)
  + echo =GNU bash, version 2.05b.0(1)-release (i386-ecce-mirbsd10)=
  =GNU bash, version 2.05b.0(1)-release (i386-ecce-mirbsd10)=
  tg@blau:~ $ mksh -xc 'foo=$(bash --version 2>&1 | head -1); echo "=$foo="'    
                                  
  + + head -1
  + foo='+ + 2>&1 bash --version' 
  + echo '=+ + 2>&1 bash --version='
  =+ + 2>&1 bash --version=

  Questionable: redirection in effect while printing trace.
  Maybe not so nice: PS4 shown twice (what happens with subsequent things?)

  
  Given: stderr redirections/parsing never safe while “set -x” is in effect.
  But maybe we can do better? Something like a trace fd?

  tg@blau:~ $ mksh-R41c -xc 'foo=$((echo foo; bash --version) 2>&1 | head -1); 
echo "=$foo="'
  + 2>&1 
  + head -1
  + foo=+ echo foo
  + echo =+ echo foo=
  =+ echo foo=
  tg@blau:~ $ mksh -xc 'foo=$((echo foo; bash --version) 2>&1 | head -1); echo 
"=$foo="'                          
  + + head -1
  + foo='+ 2>&1 + echo foo' 
  + echo '=+ 2>&1 + echo foo='
  =+ 2>&1 + echo foo=

  This clearly shows that having the redirection in effect is not a new thing,
  it just affects more cases now. (The “+ 2>&1 +” is also a cosmetic.)

  Maybe some sort of buffering or pre-preparing the output? Have to look
  at this again.

  
  Thanks to arekm from PLD Linux for reporting these issues.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1179287/+subscriptions

Reply via email to