bug-gnulib
[Top][All Lists]
Advanced

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

Re: RFC: init.sh: reject dash, due to its surprising local V='...' seman


From: Jim Meyering
Subject: Re: RFC: init.sh: reject dash, due to its surprising local V='...' semantics
Date: Mon, 8 Aug 2016 08:18:01 -0700

On Mon, Aug 8, 2016 at 4:23 AM, Pádraig Brady <address@hidden> wrote:
> On 06/08/16 21:02, Jim Meyering wrote:
>> I was burned by dash's local V=' x' semantics, in spite of having
>> reported and studied this wart, at length, a few years ago. This arose
>> again when Assaf discovered one of grep's test programs would
>> malfunction on dash-based shells, e.g., on most Debian systems:
>> https://bugs.gnu.org/24116#11
>>
>> I don't want to have to debug or think about this again -- at least
>> not in the free-software test scripts that I tend -- so propose to
>> make init.sh's initial shell-triage stage (where it tries to find a
>> useful shell, i.e., one that supports '$(...)', local and a few other
>> features) reject any shell like dash with this unfortunate and subtly
>> misleading attribute.
>>
>> While currently dash cannot be said to be nonconforming, this
>> interpretation (thanks, Eric) suggests that the behavior of bash and
>> zsh is what will be standardized, so dash should change sooner rather
>> than later:
>>
>> http://austingroupbugs.net/view.php?id=351
>>
>> In the mean time, I feel more than justified in making our tests avoid dash.
>>
>> If no one objects, I'll push this in a couple of days.
>
> Wow, yes I agree, that's very confusing behavior.

Thanks for looking.

> Do you need an `|| exit 1` in the patch.

No. Any code after that function invocation would not be reached. The
way dash currently works, its own parser exits (with status 2) upon
trying to interpret that code.

Here's a demonstration:

  $ dash -c 'f() { local t=$(printf " 1"); }; f; exit 3'; echo $?
  dash: 1: local: 1: bad variable name
  2

My only concern about using this patch as-is is for a system with dash
as its only bourne shell. For such a system, this test would cause
every init.sh-using test to be skipped. I could dumb it down so it
merely classifies dash as a marginally-acceptible shell (like those
for which set -x corrupts stderr) and thus uses it only as a last
resort. But that would add complexity -- probably not worth it for
something that ought to be fixed quickly -- so I'm inclined to take
the harder line and see what happens.



reply via email to

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