[Top][All Lists]

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

Re: Consequences of shell errors

From: Eric Blake
Subject: Re: Consequences of shell errors
Date: Thu, 18 Jun 2015 08:40:23 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 06/18/2015 08:22 AM, Chet Ramey wrote:
> On 6/18/15 9:08 AM, Eric Blake wrote:
>> On 06/18/2015 06:51 AM, Chet Ramey wrote:
>>> Neither of these are failures; the export command returns success.  In
>>> fact, according to Posix, the export command cannot fail.
>> Not quite true; export CAN fail:
>> http://austingroupbugs.net/view.php?id=351
> Introducing declaration commands that treat arguments as assignments
> implies that these are variable assignment errors, not return status
> values from export.  This interpretation doesn't change the description
> of export, which continues to list `zero' as the only possible exit
> status.

Ah, but:

$ export 1
bash: export: `1': not a valid identifier
$ echo $?

How can that be considered a variable assignment error; nothing was

$ readonly -p > /dev/full
bash: readonly: write error: No space left on device
$ echo $?

and that is certainly not a variable assignment error :)

At any rate, I'm opening a new Austin Group bug today on this topic.

>> $ bash -c 'a=1; readonly a; export a=2; echo $?'
>> bash: a: readonly variable
>> 1
>> In fact, bash _didn't_ abort, while other shells do:
> You should have tried it in posix mode to test posix behavior.

Fine; proof that an invalid variable name is not a variable assignment
error, in posix mode:

$ bash --posix -c 'export 1; echo $?'
bash: line 0: export: `1': not a valid identifier

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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