0001630: Alias names - Austin Group Defect Tracker

Notes
(0006122) kre (reporter) 2023-01-20 22:30	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 well. 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 Issue7+TC2 currently).

(0006123) kre (reporter) 2023-01-20 22:36 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.

(0006149) geoffclare (manager) 2023-02-13 17:19	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.

(0006156) mirabilos (reporter) 2023-02-18 20:33	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.

(0006171) geoffclare (manager) 2023-02-24 10:03	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.

(0006172) hvd (reporter) 2023-02-24 12:24 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" -hello In bash, bosh, gwsh, ksh, pdksh, and yash, this works: alias -- -hello="echo hello" -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" unalias dummy -hello

(0006173) geoffclare (manager) 2023-02-24 13:45	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).

(0006174) ormaaj (reporter) 2023-02-24 14:05 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.

(0006175) stephane (reporter) 2023-02-24 14:30	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]=1"; alias' alias a[1]='1' $ bash -o posix -c 'alias "a[1]=1"; alias' a[1]='1' $ bash -o posix -c 'alias "=1"; alias' ='1' 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: eval "saved_aliases=($(alias))" 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: alias a[0-9]=uname in a directory that contains a a1=uname file, it defines a a[0-9] alias instead of a1.

(0006176) hvd (reporter) 2023-02-24 14:44	> 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.

(0006177) ormaaj (reporter) 2023-02-24 14:52 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.

(0006178) kre (reporter) 2023-02-24 16:59	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.

(0006179) eblake (manager) 2023-02-27 17:37	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)

(0006181) kre (reporter) 2023-02-27 19:13	Re Note: 0006179 The script in question is wacked out, rather than "alias sed='sed --posix' it should instead do sed=sed and then in the case where the alias is defined sed="$sed --posix" 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 the script. [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.

(0006182) geoffclare (manager) 2023-02-28 14:08	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.

(0006183) steffen (reporter) 2023-03-01 23:04	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?

(0006266) geoffclare (manager) 2023-04-20 16:07 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)

Issue History
Date Modified	Username	Field	Change
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
2023-06-13 11:12	geoffclare	Status	Resolved => Applied
2023-06-13 11:13	geoffclare	Tag Attached: applied_after_i8d3

Aardvark Mark IV