bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Having an alias and a function with the same name leads to some sort


From: Martin D Kealey
Subject: Re: Having an alias and a function with the same name leads to some sort of recursion
Date: Sat, 18 Feb 2023 12:21:49 +1000

On 2/14/23 2:58 PM, Dale R. Worley wrote:

> Though I think by "keyword" he means "reserved word".
>

Yes, though in my defense, the bash man page liberally uses the term
"keyword".

On Fri, 17 Feb 2023 at 01:14, Chet Ramey <chet.ramey@case.edu> wrote

> I think the issue is that he's applying a grammar interpretation (simple
> command) to something that is a completely lexical operation.


It was not I who wrote the original description as a grammatical
interpretation. I merely tried to improve it.

(quoting OpenGroup):

> "After a token has been delimited, but before applying the grammatical
> rules in Shell Grammar, a resulting word that is identified to be the
> command name word of a simple command shall be examined to determine
> whether it is an unquoted, valid alias name."
>

(quoting the Bash man page):

> "The first word of each simple command, if unquoted, is checked to see if
> it has an alias."
>

Both of these are clearly wrong, because it's not that the word *is* the
command name of a simple command, but rather that it's in the grammatical
position where such a command name *could* occur.

To put it another way, it's not about looking at a token that's already
been consumed by the parser, it's about considering the look-ahead token,
and whether "seen command name" could be a valid possible state after
consuming it.

I want to find a way of expressing all this in English without assuming the
reader knows what "look ahead" and "state" mean in compiler theory.


I feel that "completely lexical" is misleading. Clearly alias expansion is
already specified in grammatical terms, in both the man page and by
OpenGroup, where "identified to be" clearly means in an identified
grammatical context.

As with many languages, Bash's separation of parsing into "lexical" and
"grammatical" phases is only an approximation, as there's a necessary
entanglement between them.

Alias expansion happens in the lexical analyzer, and it happens when a
> token can potentially be the first word of a simple command.
>

Logically, alias expansion happens *between* lexical tokenization and
grammatical parsing. Maybe it's implemented within the lexical analyser in
Bash, but if so that's just an implementation detail: aliases could equally
well be implemented by splitting the substitution string into lexical
tokens when the alias is defined, and then substituting that sequence of
tokens when the alias is expanded, quite disconnected from the "lexical"
phase.

>From the perspective of a user thinking about when aliases are expanded, I
think it makes more sense to consider alias expansion as a leading adjunct
to the grammatical phase rather than as a following adjunct to the lexical
phase.

I'm glad the current man page is written with that focus.

You can put any syntax element into an alias and the shell will parse it.
>

We can quibble about contextual details and whether "syntax element"
distinguishes "reserved word" from other "word" lexical tokens, but
otherwise that's adequate.

-Martin

PS: I also fudged things slightly by saying "beginning" rather than "first
word", but otherwise my phrase "beginning of a simple command" was intended
to mean precisely "word that is identified to be the command name word of a
simple command".

In hindsight "beginning" could be misconstrued as including prefix
assignments and redirections, when I had intended to mean that those should
first be skipped.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]