On 02/23/2016 02:00 PM, Harald van Dijk wrote: > > I was under the impression that the intent from the dash side was to > handle all commands the same, and that impression was based on the fact > that the . command has received additional code to handle -- even though > there's no requirement for that. However, looking into the original bug > report that prompted that change in more detail I see that the standard > will very likely require support for -- in the . command in the future, > so that doesn't hold up. Here's the link for dot and exec supporting --: http://austingroupbugs.net/view.php?id=252 > > If that intent isn't there (I'm not saying it's not; I'm unsure now), > the list of utilities that should be extended is far smaller, if I'm not > overlooking anything: > - alias > - getopts > - type > - exec? > - local? Weird that unalias already works. Oh, because of 'unalias -a'. I didn't spot any others that you missed (doesn't mean there aren't any, just that I didn't spot them). > > exec is like .: there's currently no requirement to support --, but that > requirement is likely to come in the future. See the above link; exec must support -- if '.' does. I also found http://austingroupbugs.net/view.php?id=163 which confirms that 'eval' is not required (nor it is prevented) from recognizing --. There's also http://austingroupbugs.net/view.php?id=960 which mentioned the exit status of export and several other special builtins, but added no requirements related to --. > > local is currently non-standard and it's hard to guess whether it will > require support for -- if standardised. If standardized, I expect it to require support for --, on the grounds that 'local -r' already has meaning in bash, so local is definitely a candidate for taking options. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
