All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald van Dijk <harald@gigawatt.nl>
To: Eric Blake <eblake@redhat.com>,
	Jan Verbeek <ring@openmailbox.org>,
	dash@vger.kernel.org
Subject: Re: [BUG] Illegal function names are accepted after being used as aliases
Date: Tue, 23 Feb 2016 22:00:24 +0100	[thread overview]
Message-ID: <56CCC868.8040900@gigawatt.nl> (raw)
In-Reply-To: <56CCB3F7.8090301@redhat.com>

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

  reply	other threads:[~2016-02-23 21:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-23 18:18 [BUG] Illegal function names are accepted after being used as aliases Jan Verbeek
2016-02-23 18:40 ` Eric Blake
2016-02-23 18:44 ` Harald van Dijk
2016-02-23 18:58   ` Eric Blake
2016-02-23 19:21     ` Harald van Dijk
2016-02-23 19:33       ` Eric Blake
2016-02-23 21:00         ` Harald van Dijk [this message]
2016-02-23 21:49           ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56CCC868.8040900@gigawatt.nl \
    --to=harald@gigawatt.nl \
    --cc=dash@vger.kernel.org \
    --cc=eblake@redhat.com \
    --cc=ring@openmailbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.