Re: Do test-path_is_{file,dir,exists} make sense anymore with -x?

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

 



On Mon, Mar 04, 2019 at 03:36:33PM +0100, SZEDER Gábor wrote:

> On Tue, Feb 26, 2019 at 04:01:01PM -0500, Jeff King wrote:
> > > +	{ set +x ; } 2>/dev/null 4>/dev/null
> > 
> > Ah, this is the magic. Doing:
> > 
> >   set +x 2>/dev/null
> > 
> > will still show it, but doing the redirection in a wrapping block means
> > that it is applied before the command inside the block is run. Clever.
> 
> Yeah, clever, but unfortunately (and to me suprisingly) unportable:
> 
>   $ ksh
>   $ set -x
>   $ echo foo
>   + echo foo
>   foo
>   $ set +x
>   $ 
> 
> It doesn't show 'set +x', how convenient! :)
> However:
> 
>   $ set -x
>   $ echo foo 2>/dev/null
>   + echo foo
>   + 2> /dev/null
>   foo
>   $ { set +x; } 2>/dev/null
>   + 2> /dev/null
>   $ 

Hmph. Good find. As you note, this is already a problem with "-x". I'm
not sure if there's an easy way to fix this. We can't wrap it in a
conditional function easily. I guess we could do something like:

  if test "$SOMEHOW_WE_DETECT_KSH"
  then
	eval "set -x; run_the_test; set +x"
  else
	eval "set -x; run_the_test; { set +x; } 2>/dev/null"
  fi

but I wonder if just ignoring it is a viable option here. We're talking
about debugging output from the test suite, after all. As long as the
test suite still _works_ on those shells, and as long as there are no
developers on ksh-primary systems who can't bear to use another
$TEST_SHELL_PATH, it's really not hurting anybody. The worst case is
somebody reporting a test failure on NetBSD might have a slightly more
verbose "-x" output.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux