|Anonymous | Login||2023-06-10 17:39 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001630||[1003.1(2016/18)/Issue7+TC2] Base Definitions||Objection||Clarification Requested||2023-01-20 21:39||2023-04-20 16:09|
|Priority||normal||Resolution||Accepted As Marked|
|Page Number||(page or range of pages)|
|Line Number||(Line or range of lines)|
|Final Accepted Text||Note: 0006266|
|Summary||0001630: Alias names|
I have a strong objection for alias names beginning with either ‘+’ or ‘-’ (or are exactly “[[” but that’s not yet portable anyway).
This used to not be a problem, but with the recent change to POSIX alias name characters, it has become one.
(This was, indeed, discussed with users who wanted to use +/- as aliases, but there were problems and ambiguities stemming from them (mostly wrt. options), and so mksh denies aliases to start with either of these characters.)
On page 34, lines 1168 ff., change
3.10 Alias Name
In the shell command language, a word consisting solely of alphabetics and
digits from the portable character set and any of the following characters:
3.10 Alias Name
In the shell command language, a word consisting solely of alphabetics and
digits from the portable character set and any of the following characters
(where '-' may not be used as the first character of the word):
As long as we're keeping aliases in the standard at all (no objection to
deleting them, and all that goes with them, from me), their names, just
like function names, should be able to be anything that a (simple) command
name can be, so an alias, or function, can be used to replace/augment any
command that can exist (just not ones containing '/' so using a full path
to defeat the function, or alias, though even that's not as important for
aliases, as quoting some of it also stops an alias from expanding).
Commands can begin with - and + (I use '-' as a shorthand for the nmh "prev"
command, and '+' for its "next" command), so aliases should be able to as
The current text in XBD 3.10 doesn't require support in alias names
for '+' or '-' at all, but it allows that as an implementation extension.
I object to any attempt to restrict things more than is currently done
(note: nothing requires your shell to allow '-' or '+' in alias names
at all, if you do allow them, you can do that however you like, the
standard does not have to forbid a leading '-' for you to do so.)
[[ would be a dangerous alias to attempt to use, as it is on the "might
be a reserved word" list, if it is, then (with standard posix shell practices)
it cannot be used as an alias. If it isn't, I see no reason why that
shouldn't be an alias either.
While I'm here, a procedural note which I think is correct, but someone
more knowledgeable might correct me ... you're filing your recent issues
in the "Online Pubs" category. I think that's wrong - that's intended for
issues with the HTML translation of the (primary) PDF version of the
standard. I don't think it should be used for issues with what the
standard says, or changes/additions requested of that. Use the version
of the standard you're reading (if the HTML version that would be
edited on: 2023-01-20 22:38
And I, of course, missed the changes made by 0001050 which is not
in the draft yet.
That makes no difference to my opinion of this, an alias name starting
with (or being entirely) '-' (or '+') is, and should remain, entirely
proper to have.
This was discussed in the Feb 13, 2023 teleconference. For filenames, POSIX says in XBD 4.8 (or 4.9 in D2.1):
Applications should avoid using filenames that have the <hyphen-minus> character as the first character since this may cause problems when filenames are passed as command line arguments.
We are leaning towards adopting a similar solution for alias names, but would like to know more about the problems that alias names beginning with <hyphen-minus> caused for mksh. All we have to go on at the moment is the vague mention in the description, "there were problems and ambiguities stemming from them (mostly wrt. options)". We note that shells other than mksh do not seem to have problems in this area.
I honestly don’t remember any more :|
The last mention of this is from March 2020:
| allow ‘+’ in alias names (just not as first character, like ‘-’)
mksh’s getopt has + and - as flag starters both, hence handling them the same.
The last change of “valid characters in alias names” before that was in April 2017 (: and [ but not exactly "[[")… and shortly before, - was re-added but not as first character (after we had stripped the list down to what POSIX said at that time).
That was shortly before that, and I *think* it was done in response to some user or researcher (Stéphane Chazelas is good at doing so) finding some issue with allowing “too much” in alias names.
So, sorry, I don’t recall details after five years.
I do appreciate the note asking applications not to do it; I’d appreciate it even more if an alias name beginning with [+-] could have implementation-specified behaviour (so I could continue rejecting them) but I understand if you’re reluctant to do so on the vague amount of reason I can give.
That's unfortunate. The plan was not only to decide whether to include the warning based on your feedback but also to base the "since this may cause problems when ..." part of the text on it.
For filenames, problems can occur in common everyday interactive commands typed by users, such as "ls -l *.c", if a filename beginning with '-' happens to exist. (It can occur in shell scripts as well, of course, but I think these days shell script authors are more likely to take care to include "--", whereas users don't bother in interactive commands as it's more to type.) The only similar case for aliases I can think of would be some code to unalias or show the definition of a subset of the current aliases. Something like:
for a in $alias_names; do case $a in (foo|bar) ;; (*) unalias "$a" ;; # or: alias "$a" esac done
But this is far from "common everyday" stuff.
Unless someone can come up with a use case that merits the warning, I expect we will end up rejecting this bug.
edited on: 2023-02-24 12:25
One problem is that implementations disagree on whether the 'alias' command takes options, and in those implementations where it does not take options, whether option processing happens. Because of this, it is not possible to define an alias with a name starting with '-' portably.
In dash and osh, this works:
alias -hello="echo hello"
In bash, bosh, gwsh, ksh, pdksh, and yash, this works:
alias -- -hello="echo hello"
But there is not, I believe, a way to use the alias command to define an alias named '-hello' that works in all shells (edit: and does not attempt to print the definition of any existing alias with the name '--') that allow that as an alias name unless we resort to trickery like
alias dummy=dummy -hello="echo hello"
|Re Note: 0006172 The standard requires that alias supports "alias -- operand". If dash and osh do not support it, they are non-conforming. See XCU 1.4 Utility Description Defaults (under OPTIONS).|
edited on: 2023-02-24 14:17
Relatedly, the `-p` option used by several implementations is absolutely required in order to properly save and restore alias definitions, so `alias` must support handling them. -p causes each output alias to be prefixed with an alias command so that the string may be eval'd. The format prescribed by POSIX renders the output completely useless in spite of the impossible requirement that "the value string shall be written with appropriate quoting so that it is suitable for reinput to the shell".
One could theoretically interpret that in a reasonable manner once $'' becomes available as it could then be inferred that the shell must force each definition onto a single line to be subsequently parsed by newline delimiters. That could only happen safely if each definition is required to be represented that way.
Most current implementations don't do this even if they do support $''. zsh and ksh93 seem to. bash and dash do not.
Re: Note: 0006174
I agree it's unclear what:
> suitable for reinput to the shell
means in that context. Does that mean "reinput as a scalar variable assignment"?
$ bash -c 'alias "a=1"; alias'
$ bash -o posix -c 'alias "a=1"; alias'
$ bash -o posix -c 'alias "*=1"; alias'
None of that is suitable as reinput to the shell, neither as variable assignment, neither as alias invocations as those glob characters are not quoted; one would need to set the noglob option
zsh's is suitable as reinput as:
alias -- $saved_aliases
Though of course that's not POSIX syntax and anyway zsh already exposes the list of aliases in the special $aliases associative array (not in sh emulation by default).
Another way bash is not compliant is that in:
in a directory that contains a a1=uname file, it defines a a[0-9] alias instead of a1.
> Does that mean "reinput as a scalar variable assignment"?
I have interpreted it, and dash has interpreted it, as "reinput as an operand to the alias command", so that given an existing alias foo, v=$(alias foo) can be used to save its definition, and eval "alias $v" can be used to restore it. This is why dash has also recently changed to suitably quote not only the value, but also the name (in contradiction of POSIX because POSIX is clearly utterly wrong here). zsh does the same.
Mind, this is only useful for the output of a single alias definition. For the output of multiple alias definitions, the -p option is still needed.
edited on: 2023-02-24 15:20
Bash is one of the shells that considers alias to be a declaration builtin. I suspect it will try parsing `alias a[0-9]=uname` as though it were an array assignment without globbing even though that's nonsense.
related discussion: https://github.com/ksh93/ksh/commit/b369f40ded0ec7e8dd3d4a0e7226ccf037bb3400#commitcomment-86945331 [^]
Edit: ...and indeed that's exactly what bash does. Stranger still, ksh93 (both v- and u+m) whine with an error: "cannot be an array" in spite of ksh supposedly not considering alias as a declaration command. `whence -v` says "special builtin" in v- (like typeset) while u+m says it's a regular builtin.
You all do realise that we could easily make all of this simply
go away, by deleting aliases from the standard, and leaving them
for shells to implement however they want (like "select" and "[["
and all kinds of other add-ons that are moderately common, but not
needed in the standard).
Aliases are an absurd feature to have standardised (they're absurd
in any event, but never mind) - the very thought of a portable
script attempting to use aliases in some productive way is frightening.
|https://git.sv.gnu.org/cgit/gnulib.git/tree/gnulib-tool?id=355e89bcb#n102 [^] is an example of a script that DOES try to use 'alias' as a feature, but where the item being aliased does not use leading '-' nor trailing ' ', and where even the attempt at (ab)using aliases is further conditionalized on being run by particular shells rather than trying to be portable to all POSIX sh. The fact that aliases are that hard to portably use in scripts is indeed an argument in favor of leaving aliases as an implementation extension, but I'm not sure if we have time to do that for Issue 8 (not least of which we need proposed wording changes)|
Re Note: 0006179
The script in question is wacked out, rather than "alias sed='sed --posix'
it should instead do
and then in the case where the alias is defined
and then use $sed everywhere instead of sed (as a command name).
The script as it is probably works as run as a command, or as a filename
arg to sh, but isn't guaranteed to work if run as ". script" since in that
case the shell is allowed to parse the whole thing before running any of it,
and in that case the alias command executes too late to alter anything in
[Aside: I do understand the temptation to do it the alias way, as when it
does work, it avoids needing changes elsewhere in the script, along with
the possibility that some might get missed - but it is still the wrong way.]
I think the changes could be made for Issue 8, apart from needing to add
"alias" and "unalias" to wherever is appropriate to tell users not to use
as arbitrary commands, the changes are almost all simply deleting stuff.
If there were agreement that this change can be made (ie: if the minutes
from a meeting say something like "if the changes needed to remove aliases
from the standard are made available, it was agreed to delete aliases from
the standard") then I'll take a look at finding all the relevant places and
suggesting what changes ought to be made.
|We cannot remove aliases without first making them obsolescent. So the route to getting them removed would be to request adding OB shading in Issue 8. Then they can be removed in Issue 9.|
Despite kre's repulsion against macros, they are implemented anywhere, and i would wildly claim that the majority of shell users use them, .. for decades.
Why should such a feature be removed?
edited on: 2023-04-20 16:09
On draft 3 page 2462 line 79899 section 2.3.1, change:
• the TOKEN could be parsed as the command name word of a simple command ...to:
• either the TOKEN is being considered for alias substitution because it follows an alias substitution whose replacement value ended with a <blank> (see below) or the TOKEN could be parsed as the command name word of a simple command ...
After draft 3 page 2565 line 83832 section alias, add:
5. Add the -F option to interactive uses of ls, even when executed as <tt>xargs ls</tt> or <tt>xargs -0 ls</tt>:alias ls='ls -F' alias xargs='xargs ' alias -- -0='-0 ' find . [...] -print | xargs ls # breaks on filenames with \n (two aliases expanded) find . [...] -print0 | xargs -0 ls # minimizes \n issues (three aliases expanded)
|2023-01-20 21:39||mirabilos||New Issue|
|2023-01-20 21:39||mirabilos||Name||=> mirabilos|
|2023-01-20 21:39||mirabilos||Organization||=> mksh|
|2023-01-20 21:39||mirabilos||URL||=> https://austingroupbugs.net/view.php?id=1050 [^]|
|2023-01-20 21:39||mirabilos||Section||=> 3.10|
|2023-01-20 22:30||kre||Note Added: 0006122|
|2023-01-20 22:36||kre||Note Added: 0006123|
|2023-01-20 22:38||kre||Note Edited: 0006123|
|2023-02-09 17:08||nick||Relationship added||related to 0001050|
|2023-02-09 17:09||geoffclare||Project||Online Pubs => 1003.1(2016/18)/Issue7+TC2|
|2023-02-13 17:19||geoffclare||Note Added: 0006149|
|2023-02-18 20:33||mirabilos||Note Added: 0006156|
|2023-02-24 10:03||geoffclare||Note Added: 0006171|
|2023-02-24 12:24||hvd||Note Added: 0006172|
|2023-02-24 12:25||hvd||Note Edited: 0006172|
|2023-02-24 13:45||geoffclare||Note Added: 0006173|
|2023-02-24 14:05||ormaaj||Note Added: 0006174|
|2023-02-24 14:08||ormaaj||Note Edited: 0006174|
|2023-02-24 14:09||ormaaj||Note Edited: 0006174|
|2023-02-24 14:14||ormaaj||Note Edited: 0006174|
|2023-02-24 14:17||ormaaj||Note Edited: 0006174|
|2023-02-24 14:30||stephane||Note Added: 0006175|
|2023-02-24 14:44||hvd||Note Added: 0006176|
|2023-02-24 14:52||ormaaj||Note Added: 0006177|
|2023-02-24 15:10||ormaaj||Note Edited: 0006177|
|2023-02-24 15:11||ormaaj||Note Edited: 0006177|
|2023-02-24 15:20||ormaaj||Note Edited: 0006177|
|2023-02-24 16:59||kre||Note Added: 0006178|
|2023-02-27 17:37||eblake||Note Added: 0006179|
|2023-02-27 19:13||kre||Note Added: 0006181|
|2023-02-28 14:08||geoffclare||Note Added: 0006182|
|2023-03-01 23:04||steffen||Note Added: 0006183|
|2023-04-20 16:07||geoffclare||Note Added: 0006266|
|2023-04-20 16:09||geoffclare||Note Edited: 0006266|
|2023-04-20 16:09||geoffclare||Page Number||=> (page or range of pages)|
|2023-04-20 16:09||geoffclare||Line Number||=> (Line or range of lines)|
|2023-04-20 16:09||geoffclare||Interp Status||=> ---|
|2023-04-20 16:09||geoffclare||Final Accepted Text||=> Note: 0006266|
|2023-04-20 16:09||geoffclare||Status||New => Resolved|
|2023-04-20 16:09||geoffclare||Resolution||Open => Accepted As Marked|
|2023-04-20 16:10||geoffclare||Tag Attached: issue8|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|