Date: Wed, 9 Jan 2019 13:55:16 +0100
From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de>
Message-ID: <5c35ef34.clu1godeocvhzivr%joerg.schill...@fokus.fraunhofer.de>
| Well, the original Bourne Shell did not have aliases.
Yes, I know that...
| I believe that csh introduced an alias concept in 1979 that works completely
| different from what ksh implemented much later.
Yes, I think the ashell version was rather simpler, but certainly the csh
aliases were quite different.
| The difference, I believe is that alias expansion happens at a different
| location in csh.
Yes, it has the whole command line of the command containing the alias
available, and can use parts of that command (or of previous commands,
using the history mechanisms) as part of the generated expansion.
| Then in 1980, former AT&T people that created the company "Charles River
Data
| Systems" and the first UNIX clone "UNOS" created an alias implementation
| concept that sits in the lexer and expands text. This is the most powerful
| alias concept that has been implemented for expansion in the lexer.
That's interesting - I had the misfortune to use unos for a (short)
while, and don't recall ever knowing of that.
| For this reason, it it natural not to implement a special meaning for "\ ".
| ksh88 and ksh93 seem to be the only shells that implement a special meaning
for
| "\ " here.
Which special meaning do you refer to there?
| > the replacement test would be, effectively
| >
| > "ls -cF" .
| >
| > (the quotes would not be there, but the ls -CF
| > part would be a single 6 character word) and that
| > would be the command word of the generated command.
|
| This does not happen as the lexer is called again and creates two word
tokens
| from the alias replacement.
Yes, I know that, but that isn't what the current published standard says
(which is why bug report 953 was filed I assume, what the standard said
about aliases was nothing like reality.)
| > In the example in question here, the original text is
| >
| > 3>&1 command
| >
| > and we have "alias 3=4"
| "3" is not a word that is in a position of a potential command name.
As far as the lexer is concerned it is.
| If the lexer did parse the input in a way that does not connect "3" to the
IO
| redirection,
It is connected, in the sense that it is an IO_NUMBER, but that is a word.
| it would be alias expanded,
Did you mean "not" there?
| since the knowledge about "a word at a
| position suitable for a command name" is not in the lexer.
Yes.it is, it has to be to implement aliasing the way the
standard requires (assuming that aliasing is done in the
lexer, which it almost always is). It might not be available
in your shell, but it generally is in others. The grammar
(well, the parser, using the grammar) makes it known when
it is fetching a token which could be the command name of
a simple command (then the lexer uses that info to decide
whether to do an alias lookup - usually the lexer also does
keyword lookups as well, and returns different token names
for the different keywords, but that's just an implementation
choice).
None of this matters as long as Geoff's recent new proposed
wording as the resolution of 953 is (mostly) accepted, as all
of these issues are cleaned up - it is no longer "word" that
is expanded, but TOKEN, wich is a subset of word that does
not include the IO_NUMBER.
kre
