Re: [BUG] Illegal function names are accepted after being used as aliases
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 signature.asc Description: OpenPGP digital signature
Re: [BUG] Illegal function names are accepted after being used as aliases
On 23/02/2016 20:33, Eric Blake wrote: exit - fuzzy. exit is a special built-in (unlike getopts); and XCU 2.14 states: "Some of the special built-ins are described as conforming to XBD Utility Syntax Guidelines. For those that are not, the requirement in Utility Description Defaults that "--" be recognized as a first argument to be discarded does not apply and a conforming application shall not use that argument. " Conforming apps cannot expect 'exit -1' to work, and therefore, cannot also expect 'exit -- -1' to work, since the only standards-defined values for an argument to exit is a non-negative decimal integer less than 256. Of course, if you want to fix it along with all the others, that's fine; I'm just pointing out that 'exit' isn't broken as-is. 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. 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? exec is like .: there's currently no requirement to support --, but that requirement is likely to come in the future. local is currently non-standard and it's hard to guess whether it will require support for -- if standardised. Cheers, Harald van Dijk -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Illegal function names are accepted after being used as aliases
On 02/23/2016 12:21 PM, Harald van Dijk wrote: > On 23/02/2016 19:58, Eric Blake wrote: >> On 02/23/2016 11:44 AM, Harald van Dijk wrote: >> >>> This matches bash's behaviour, aside from bash requiring -- to prevent >>> detection of invalid flags to the alias command: >>> >>> bash-4.3$ alias -- -=true >> >> Then dash DOES have a bug: > > Indeed, I wasn't trying to suggest otherwise, my apologies if it came > across that way. It's not limited to the alias command though, I spotted > at least the exit and getopts commands having the same problem, and it > should probably be fixed for all of them at once. getopts - definitely needs a fix exit - fuzzy. exit is a special built-in (unlike getopts); and XCU 2.14 states: "Some of the special built-ins are described as conforming to XBD Utility Syntax Guidelines. For those that are not, the requirement in Utility Description Defaults that "--" be recognized as a first argument to be discarded does not apply and a conforming application shall not use that argument. " Conforming apps cannot expect 'exit -1' to work, and therefore, cannot also expect 'exit -- -1' to work, since the only standards-defined values for an argument to exit is a non-negative decimal integer less than 256. Of course, if you want to fix it along with all the others, that's fine; I'm just pointing out that 'exit' isn't broken as-is. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [BUG] Illegal function names are accepted after being used as aliases
On 02/23/2016 11:44 AM, Harald van Dijk wrote: > This matches bash's behaviour, aside from bash requiring -- to prevent > detection of invalid flags to the alias command: > > bash-4.3$ alias -- -=true Then dash DOES have a bug: # dash $ alias -- -='echo hi' alias: -- not found $ echo $? 1 $ - hi $ POSIX XCU 1.4 is clear: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html "Default Behavior: When this section is listed as "None.", it means that the implementation need not support any options. Standard utilities that do not accept options, but that do accept operands, shall recognize "--" as a first argument to be discarded." and alias takes operands, stating "OPTIONS: None.", which means POSIX _requires_ 'alias -- -=name' to (attempt to) define only the single alias '-', and NOT to also attempt to define '--' as an alias. It's okay if dash allows 'alias -=blah' to define '-' as an alias as an extension, but it MUST ignore '--' the way bash does. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [BUG] Illegal function names are accepted after being used as aliases
On 02/23/2016 11:18 AM, Jan Verbeek wrote:
> Function definitions that use a bad function name (such as "-" and "=")
> are accepted if the function name already exists as an alias. For example:
Not necessarily a bug.
>
> $ -
> dash: 1: -: not found
> $ - () { echo hello; }
> dash: 2: Syntax error: Bad function name
> $ -
> dash: 2: -: not found
> $ alias -=true
> $ -
This is equivalent to running 'true'.
> $ - () { echo hello; }
This is equivalent to running 'true () { echo hello; }' - the alias
expansion happens BEFORE the function definition is even parsed. You
are NOT defining a function named '-', but one named 'true'.
> $ -
This is again equivalent to running 'true' - except that now the
function name 'true' exists and bypasses the shell builtin.
> hello
> $
So the only thing remaining is to determine if it is legal to have a
function override the name of a regular shell builtin. But
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
under "Command Search and Execution" states that function names have
priority over regular built-ins (so yes, creating a function named
'true' is doable, although stupid).
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
