[Top][All Lists]

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

Re: Bash-4.3 Official Patch 25

From: Eric Blake
Subject: Re: Bash-4.3 Official Patch 25
Date: Thu, 25 Sep 2014 18:49:28 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

On 09/25/2014 05:58 PM, Chet Ramey wrote:
> On 9/24/14, 5:38 PM, Eric Blake wrote:
>> and I'd feel much more comfortable with exporting f()=... as the
>> backdoor for passing the function definition, _particularly_ since the
>> shell already allows functions and variables to co-exist:
> We used to do that, and part of the code that I removed in patch 25
> supported the original `name()=() {'.  We didn't use that very long; it
> turns out that the Bourne shell (and others, at that time) dumps core on
> malformed environment variable names.  It's why we stuck with shell
> identifiers, though the check for that didn't come in until later.
> I'd be willing to bet that the Bourne shell that still runs on Solaris,
> AIX, HP-UX, and SCO (if anyone still runs that) has this problem.

I just tested on Solaris 9 (the oldest machine I have easy access to),
and /bin/sh there silently ignored things without crashing:

$ env 'foo()=()' /bin/sh -c 'env | grep foo'
$ env 'foo()=()' bash -c 'env | grep foo'
$ uname -a
SunOS XXXXXX 5.9 Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise-T5220

While it may have been a problem in the past, I don't think systems old
enough to have an 'sh' that dumps core on odd environment variables are
still worth worrying about in the present.

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]