bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
Date: Thu, 09 Sep 2010 08:26:03 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.2

On 09/09/2010 03:37 AM, Jim Meyering wrote:
@@ -269,7 +305,18 @@ path_prepend_()

  setup_()
  {
-  test "$VERBOSE" = yes&&  set -x
+  if test "$VERBOSE" = yes; then
+    # Test whether set -x may cause the selected shell to corrupt an
+    # application's stderr.  Many do, including zsh-4.3.10 and the /bin/sh
+    # from SunOS 5.11, OpenBSD 4.7 and Irix 5.x and 6.5.
+    # If enabling verbose output this way would cause trouble, simply
+    # issue a warning and refrain.
+    if $gl_set_x_corrupts_stderr_; then
+      warn_ "using SHELL=$SHELL with 'set -x' corrupts stderr"
+    else
+      set -x

You cannot reliably depend on set -x inside a shell function affecting the parent, no thanks to zsh:

$ bash -c 'f() { set -x; }; echo $-; f; echo $-'
hBc
+ echo hxBc
hxBc
$ zsh -c 'emulate sh; f() { set -x; }; echo $-; f; echo $-'
b
b

So for true robustness, your set -x has to be at the top level, rather than inside a function. On the other hand, zsh passes the test of not having noisy stderr, so zsh will never encounter that set -x condition in the first place; and unless any other shell shares zsh's misbehavior regarding set -x within a function, I guess this patch is okay as-is.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]