[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Not to set PIPESTATUS unless necessary
From: |
Andreas Kähäri |
Subject: |
Re: Not to set PIPESTATUS unless necessary |
Date: |
Sat, 18 May 2024 18:33:29 +0200 |
On Sat, May 18, 2024 at 08:56:57AM -0500, Peng Yu wrote:
> On Sat, May 18, 2024 at 5:21 AM Andreas Kähäri <andreas.kahari@abc.se> wrote:
> >
> > On Sat, May 18, 2024 at 04:54:05AM -0500, Peng Yu wrote:
> > > It seems the problem is the definition of pipeline is wrong. If there is
> > > just one command, it can not be separated by control operators. Therefore,
> > > a pipeline must be made of two or more commands.
> > >
> > > “ A pipeline is a sequence of one or more commands separated by one of the
> > > control operators ‘|’ or ‘|&’.”
> > >
> > > The dictionary definition of pipeline is below. There must be transmission
> > > of information in a pipeline. With just one command, there can not be a
> > > pipeline.
> > >
> > > https://www.merriam-webster.com/dictionary/pipeline
> > >
> > > “ a direct channel for information”
> > >
> > > Therefore, the current implementation appears to be a bug for following an
> > > error in the manual.
> >
> > You would also need to take the POSIX standard's definiton of a pipeline
> > into account, which I belive would trumph any dictionary's definition
> > when it comes to implementing a Unix shell:
> >
> > A pipeline is a sequence of one or more commands separated by
> > the control operator '|'. [1]
> >
> > This is more or less the same as what you found in the bash manual,
> > except for the extension that bash provides with |&
>
> In that case, the POSIX is also defective. It is an impossibility that
> one command is separated by a control operator. Even we don't consider
> the pipeline issue, "one or more commands separated by the control
> operator '|'." is still wrong. It should have been written as "one
> COMMAND or more commands separated by the control operator '|'."
>
> "A pipeline is a sequence of one or more commands separated by the
> control operator '|'."
>
> "[!] command1 [ | command2 ...]"
>
> Nevertheless, considering a single command as a pipeline, it is a
> corruption of the language. Although corruption of human language in
> other areas has more significant consequences, it doesn't mean that we
> should tolerate language corruption in programming.
>
> https://fee.org/articles/the-corruption-of-language/
But a single command _is_ a pipeline in the dictionary sense:
<input some-command >output
Here, "some-command" is made up of an arbitrary complex set
of commands. If it's just a single command, it does not
matter. It's still "a direct channel for information" and "a
process or channel of supply". It's a filter, a pipeline
processing input and producing output. It's a fundamental
component of Unix shell scripting.
The pipe _symbol_ is just the glue between the sections of pipe,
connecting the previous pipe section to the next, if there is
one. Even if there is only one pipe section, it's still a
pipeline, connecting input to output.
>
> The English meaning of "pipeline" must involve transmission of
> something. If POSIX uses "pipeline" it shall not include a single
> command, or in the formal grammar, it could rename "pipeline" as
> "command_or_pipeline". This resolves the language corruption issue.
>
> > In the same document, you'll find the more formal grammar:
> >
> > pipeline : pipe_sequence
> > | Bang pipe_sequence
> > ;
> > pipe_sequence : command
> > | pipe_sequence '|' linebreak command
> > ;
> > command : simple_command
> > | compound_command
> > | compound_command redirect_list
> > | function_definition
> > ;
> >
> > As you can see, a "pipeline" is made up from a "pipe sequence" or a "!"
> > followed by such a sequence. A "pipe sequence" is a single "command" or
> > a "pipe sequence" followed by a "|" character, an (optional) linebreak
> > and a "command". What a "command" is in the grammar should be self
> > evident.
> >
> > On a higher level, a "program" is made up from "complete commands",
> > which are separate "lists" (AND-OR lists), which are single or multiple
> > "pipelines" separated by "||" or "&&".
> >
> >
> > [1]
> > https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/V3_chap02.html#tag_18_09_02
> >
> >
> > >
> > > On Sat, May 11, 2024 at 1:28 PM Chet Ramey <chet.ramey@case.edu> wrote:
> > >
> > > > On 5/10/24 5:13 PM, Peng Yu wrote:
> > > >
> > > > >> I don't
> > > > >> think an option to do this would be useful.
> > > > >
> > > > > I've already shown use cases where it may be useful. After all, it is
> > > > > not necessary to diligently set PIPESTATUS duplicating the info in $?
> > > > > for simple commands.
> > > >
> > > > I don't think it's generally useful enough to implement a special option
> > > > in the shell itself to enable it. It's easy enough to save $PIPESTATUS
> > > > if you want its value.
> > > >
> > > > --
> > > > ``The lyf so short, the craft so long to lerne.'' - Chaucer
> > > > ``Ars longa, vita brevis'' - Hippocrates
> > > > Chet Ramey, UTech, CWRU chet@case.edu
> > > > http://tiswww.cwru.edu/~chet/
> > > >
> > > > --
> > > Regards,
> > > Peng
> >
> > --
> > Andreas (Kusalananda) Kähäri
> > Uppsala, Sweden
> >
> > .
>
>
>
> --
> Regards,
> Peng
--
Andreas (Kusalananda) Kähäri
Uppsala, Sweden
.
- Not to set PIPESTATUS unless necessary, Peng Yu, 2024/05/08
- Re: Not to set PIPESTATUS unless necessary, Koichi Murase, 2024/05/18
- Re: Not to set PIPESTATUS unless necessary, Peng Yu, 2024/05/18
- Re: Not to set PIPESTATUS unless necessary, Koichi Murase, 2024/05/18
- Re: Not to set PIPESTATUS unless necessary, Greg Wooledge, 2024/05/18
- Re: Not to set PIPESTATUS unless necessary, Lawrence Velázquez, 2024/05/19
- Re: Not to set PIPESTATUS unless necessary, Peng Yu, 2024/05/19