a COMMAND is a WORD says somewhere .. somewhere .. On Thu, Dec 12, 2024, 5:56 PM Mike Jonkmans <bash...@jonkmans.nl> wrote:
> On Thu, Dec 12, 2024 at 03:56:52AM -0500, Lawrence Velázquez wrote: > > On Thu, Dec 12, 2024, at 2:01 AM, Mike Jonkmans wrote: > > > Yes, the posix grammar doesn't allow it. > > > But it is not clear, from the bash documentation, > > > that a pipeline is not a command. > > Sure, the documentation doesn't explicitly say that. > > AFAIAC the documentation is what this is about. > Posix or yacc grammar terms do not correspond exactly to the notions > in the documentation of bash. > I.e. 'command' is used but not defined in the doc's SHELL GRAMMAR. > > > But it also doesn't say that pipelines are composed of pipelines, > > the way it says that lists are composed of pipelines. > > So why would you make that assumption? > > Given the doc's definition of a pipeline: > [time [-p]] [ ! ] command [ [|⎪|&] command2 ... ] > > and note that nowhere else is a '!' found in the doc's grammar. > > So the only way - given the doc - to parse '! ! false' > is by having a pipeline as command. > > > > Moreover, bash accepts e.g.: > > > ! ! false > > > How can you parse that, without a pipeline being a command? > > The yacc grammar uses two separate non-terminals to realize the > > colloquial notion of a "pipeline": > > Yes, I am familiar with yacc. But it is about the documentation's grammar. > > > > And, as said, ksh allows the construct (! true | ! true). > > > It is not impossible, it just is not posix. > > Of course it's not impossible, it's just goofy. A pipeline like: > > ! true | ! true | ! true > > looks like it's composed of several segments that are each being > > individually "negated", but it's logically equivalent [*] to: > > ! ! ! true | true | true > > so why allow the confusion? (POSIX doesn't permit the latter either, > > which is consistent at least.) > > [*]: Yes, I know that in bash ! ! just cancels out, so it probably > > wouldn't be *exactly* the same. > > PIPESTATUS and pipefail would make it different. > Useful? Maybe. But one can easily workaround it. > Note that I am not advocating a change in code in this thread. > > -- > Regards, Mike Jonkmans > >
