From: Eric Blake <eblake@redhat.com>
To: Harald van Dijk <harald@gigawatt.nl>,
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 14:49:43 -0700 [thread overview]
Message-ID: <56CCD3F7.3070802@redhat.com> (raw)
In-Reply-To: <56CCC868.8040900@gigawatt.nl>
[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
prev parent reply other threads:[~2016-02-23 21:49 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
2016-02-23 21:49 ` Eric Blake [this message]
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=56CCD3F7.3070802@redhat.com \
--to=eblake@redhat.com \
--cc=dash@vger.kernel.org \
--cc=harald@gigawatt.nl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).