bug-bash
[Top][All Lists]
Advanced

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

Re: Shell Grammar man page


From: Mike Jonkmans
Subject: Re: Shell Grammar man page
Date: Wed, 24 Feb 2021 01:31:13 +0100

On Tue, Feb 23, 2021 at 04:33:44PM -0500, Chet Ramey wrote:
> On 2/22/21 8:11 AM, Mike Jonkmans wrote:
> > 
> > Hi,
> > 
> > It seems some things are missing in the bash manual.
> > Notably definition of command and placements of coproc- and 
> > function-definition.
> > 
> > The section 'SHELL GRAMMAR' describes:
> > - simple-command
> > - pipeline
> > - list
> > - compound-command
> > - coproc
> > - function-definition
> 
> These are basically the `command' productions from the grammar. The
> exception is `list', and it's there because it would be strange for
> the reader if it were presented before simple commands and pipelines,
> which users are more likely to encounter, even though a complete
> command is technically a list.

It is mostly recursive, so you have to start somewhere.
Your reasoning is understandable. Start with what the reader knows.
Though the readers are likely to be familiar with grammars/rules/start symbols.

Because 'command' is not described, a reader might think that all these items
are commands.

> > Simplified, a pipeline is:
> >     [ ! ] command1 [ | command2 ]
> > 
> > A list is a sequence of pipelines separated by ;, &, &&, or ||
> > and optionally terminated by ;, & or NL.
> > 
> > Within the list description, the and-list and or-list are described as:
> >     and-list: command1 && command2
> >     or-list: command1 || command2
> > Though the text says that and/or-lists are sequences of pipelines
> > (separated by && or ||).
> 
> `command1' and `command2' are meta-notation, not a grammar production.

I know. It is just as the man page describes it. 
The numbering is quite handy for referring in the text. 

> > That is slightly inconsistent.
> Not really.
> 
> > A pipeline can be reduced to a command.
> In a sense, yes, depending on your definition of `command'.

That is the point. The documentation never describes what a 'command' is.
The inconsistency comes when you try to follow the documentation's
use of 'command'. It is only in the words, not in the real grammar of course.

> > In that case, the and/or list should read:
> >     and-list: pipeline1 && pipeline2
> >     or-list: pipeline1 || pipeline2
> 
> No, it really shouldn't.

You're right. These pipelines should be lists.
In the mean time i have looked into parse.y
The grammar is quite readable. Good.

> The bash grammar is a little messier than that POSIX grammar in
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10_02
> but it's basically the same.

Thanks for the link.

> Where are you trying to go with this?

I have been wondering about this (missing command description) for some time.
Before even trying to submit a rewrite, i wanted to make it more clear.

For me, it is clear now.
But i am not sure whether a rewrite is worth the trouble.
It is also a bit problematic that the word 'command' is overloaded.
We give commands, not lists. Though a pipeline might be entered ;)


Regards, Mike Jonkmans



reply via email to

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