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: Jim Meyering
Subject: Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
Date: Wed, 08 Sep 2010 16:45:36 +0200

Eric Blake wrote:

> On 09/08/2010 07:20 AM, Jim Meyering wrote:
>> grep portability testing has exposed some unwarranted test failures.
>> Using a better SHELL was the quick work-around.
>> Fixing init.sh is the real fix:
>>
>>> From d79a9c27419cc4679620b9283351566ba6085cd2 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering<address@hidden>
>> Date: Wed, 8 Sep 2010 15:18:46 +0200
>> Subject: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
>
> I'm a little worried that this patch might exclude all shells on a
> given platform.  For example, on IRIX 5.3:
>
> $ /bin/sh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null'
> P=1
> $ /bin/ksh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null'
> + P=1
> $ bash -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null'
> $
>
> If bash is manually installed, then things are okay.  But all existing
> shells on a bare-bones installation output trace information.

If that happens, the result will be that each init.sh-using test
will be skipped.

> Maybe a compromise is to test that if there is output, is it at least
> proceeded by PS4 (in which case it can be filtered), so as not to
> outright rejecting /bin/ksh, but still exclude /bin/sh as
> unfilterable?

But then each init.sh-using test must be audited
to discover if/where this makes a difference, and then
we'd have to modify offenders to filter out those bogus lines.

All for what?  To avoid skipping tests when run an ancient
system like Irix 5.x that lacks a usable shell.

Polluting our code, even "mere" tests, solely to accommodate an
inferior or old system is hard for me to justify.  I think it scales
better simply to eliminate the offending shells -- then we avoid
the constant overhead of auditing for yet another portability nit.

Of course, if this turns out to affect too many (and more modern)
systems, then I'll be the first to look for a lower-impact solution.

Besides, isn't Irix 5.x approaching effective museum-only status?



reply via email to

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