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' 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
signature.asc
Description: OpenPGP digital signature
