Re: Is ksh93's default alias command='command ' POSIX compliant?
Op 14-06-20 om 18:03 schreef shwaresyst: The command alias is nominally conforming, I believe, in that recursive alias expansion isn't permitted so looking for a utility named command still occurs. So are you saying that, in order to be POSIXly sure of running a standard command 'foo' given the default shell alias configuration, you have to do "command command foo" or "\command foo"? Surely that can't be the intention...? However, the implementation of various utilities as aliases changes the reporting of 'command -v', or '-V', to that they are aliases and not actual utilities as a user might expect. Such a change may be allowed, but I don't see it as intended for the utilities the standard requires. The definition of times only as an alias, in the manner used, is not conforming; the use of curly braces, being keywords, turns it into a compound command the command utility is not expected to see as an argument list, and defeats the recognition of times as a special built-in per XCU 2.9.1, as time is a regular utility. In fact, that's what all such aliases do, whether they have extra shell grammar or not. If 'unalias -a' deletes it, it's not a regular utility. There still needs to be an implementation that is accessed when "\times", to disable expansion as a possibility, is specified as well, that I see. Yes, there is that too. I believe that logically means that all standard commands should be regular or special builtins, because having a default alias overriding a default builtin only to exhibit the same behaviour is 100% pointless. Thanks for the feedback. - M. -- || modernish -- harness the shell || https://github.com/modernish/modernish || || KornShell lives! || https://github.com/ksh93/ksh
RE: Is ksh93's default alias command='command ' POSIX compliant?
The command alias is nominally conforming, I believe, in that recursive alias
expansion isn't permitted so looking for a utility named command still occurs.
However, the implementation of various utilities as aliases changes the
reporting of 'command -v', or '-V', to that they are aliases and not actual
utilities as a user might expect. Such a change may be allowed, but I don't see
it as intended for the utilities the standard requires.
The definition of times only as an alias, in the manner used, is not
conforming; the use of curly braces, being keywords, turns it into a compound
command the command utility is not expected to see as an argument list, and
defeats the recognition of times as a special built-in per XCU 2.9.1, as time
is a regular utility. There still needs to be an implementation that is
accessed when "\times", to disable expansion as a possibility, is specified as
well, that I see.
On Sunday, June 14, 2020 Martijn Dekker wrote:
I am now the maintainer of what is currently, to the best of my
knowledge, the only actively developed fork of AT ksh93. It is based
on the last stable AST version, 93u+ 2012-08-01. Along with a few others
I have been fixing a bunch of bugs. See https://github.com/ksh93/ksh for
the current activity and some history/rationale in the README.md.
One issue is ksh39's default alias
command='command '
which continues alias substitution after 'command', defeating its
ability to bypass aliases.
I think that doing this by default violates POSIX, because 'command' is
specified as a regular builtin, not as an alias. So I have removed it:
https://github.com/ksh93/ksh/commit/61d9bca5
There is some disagreement about that, however -- as you can see in the
comment under that commit (scroll all the way down). And of course it is
possible that I am wrong. So I would like the ask the Austin Group's
opinions. Does this alias, by virtue of being default, violate POSIX?
One issue in particular I would note: on 93u+, 'times' is defined as a
default alias
times='{ { time;} 2>&1;}'
which not only does not produce POSIX compliant output, but also does
not combine with the default 'command' alias: 'command times' is a
syntax error. And that is a perfectly valid POSIX idiom, so at the very
least, that seems like a straight-up standards violation. However, I
have already replaced the 'times' alias by a proper POSIX compliant
builtin on my version. This does demonstrate a problem, however; since
aliases can contain arbitrary shell grammar, continuing alias expansion
after 'command' seems problematic even if it doesn't violate POSIX.
[Possibly, this alias was added to make 'command' work with some
POSIX commands that are also defined as default aliases, i.e. 'fc',
'hash', 'times', and 'type' -- as well as some ksh-specific
scripting-relevant commands: 'autoload', 'compound', 'float',
'functions', 'integer', 'nameref', 'redirect'. I think defining
any of these as aliases is a bug in itself, as 'unalias -a' removes
all of them, so it is impossible for a script to start with a clean
alias slate without losing essential commands. That's why I'm in the
process of converting all of these to proper builtin commands.]
- Martijn
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
Is ksh93's default alias command='command ' POSIX compliant?
I am now the maintainer of what is currently, to the best of my
knowledge, the only actively developed fork of AT ksh93. It is based
on the last stable AST version, 93u+ 2012-08-01. Along with a few others
I have been fixing a bunch of bugs. See https://github.com/ksh93/ksh for
the current activity and some history/rationale in the README.md.
One issue is ksh39's default alias
command='command '
which continues alias substitution after 'command', defeating its
ability to bypass aliases.
I think that doing this by default violates POSIX, because 'command' is
specified as a regular builtin, not as an alias. So I have removed it:
https://github.com/ksh93/ksh/commit/61d9bca5
There is some disagreement about that, however -- as you can see in the
comment under that commit (scroll all the way down). And of course it is
possible that I am wrong. So I would like the ask the Austin Group's
opinions. Does this alias, by virtue of being default, violate POSIX?
One issue in particular I would note: on 93u+, 'times' is defined as a
default alias
times='{ { time;} 2>&1;}'
which not only does not produce POSIX compliant output, but also does
not combine with the default 'command' alias: 'command times' is a
syntax error. And that is a perfectly valid POSIX idiom, so at the very
least, that seems like a straight-up standards violation. However, I
have already replaced the 'times' alias by a proper POSIX compliant
builtin on my version. This does demonstrate a problem, however; since
aliases can contain arbitrary shell grammar, continuing alias expansion
after 'command' seems problematic even if it doesn't violate POSIX.
[Possibly, this alias was added to make 'command' work with some
POSIX commands that are also defined as default aliases, i.e. 'fc',
'hash', 'times', and 'type' -- as well as some ksh-specific
scripting-relevant commands: 'autoload', 'compound', 'float',
'functions', 'integer', 'nameref', 'redirect'. I think defining
any of these as aliases is a bug in itself, as 'unalias -a' removes
all of them, so it is impossible for a script to start with a clean
alias slate without losing essential commands. That's why I'm in the
process of converting all of these to proper builtin commands.]
- Martijn
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
