On 09/26/2014 08:22 AM, Zack Weinberg wrote: > On September 26, 2014 3:53:53 AM EDT, lolilolicon <lolilolicon@xxxxxxxxx> wrote: >> On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh <bash@xxxxxxxxx> wrote: > >>> This behavior has been around for 20+ without it being judged "so >> bad", >> >> I don't think that's a sufficient argument for "this is not so bad". >> >> First, the fact that the bug has existed for so long, yet fails to be >> discovered [disclosed] until now, is proof that this feature is very >> little used and rarely tested, not an argument for "it's not so bad". > > The question in my mind is, is exporting functions a POSIX shell feature? If not, perhaps it should just be scrapped altogether. Why not read POSIX and find out for yourself? http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export export -f is not required by POSIX, so it is a shell extension. But people DO rely on it, so nuking it now would be a backwards incompatible break. I'd still like to keep it, but with a smarter implementation. Other messages on the list have suggested smarter implementations, such as using 'BASH_FUNC_foo()=...' instead of 'foo=() {' as the magic for doing the export, thus eliminating the collision. I _also_ agree that since function exports are NOT required by POSIX, that it would be okay if we let /bin/bash continue to import functions by default, but have bash invoked as /bin/sh refuse to do imports by default. If the ability to import functions becomes conditional on argv[0], then I also suggest that bash have a 'set -o' option or 'shopt' setting that can let the user override the default (a way to invoke /bin/sh but with function imports, or a way to invoke /bin/bash but with no functions). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
