zsh-users
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@brasslantern.com>
To: matthi@finlandia.Infodrom.North.DE (Matthias Kopfermann),
	zsh-users@math.gatech.edu
Subject: Re: pipelines and &&
Date: Mon, 25 May 1998 09:38:00 -0700	[thread overview]
Message-ID: <980525093801.ZM13568@candle.brasslantern.com> (raw)
In-Reply-To: <m0ydtqL-001MsmC@finlandia.Infodrom.North.DE>

On May 25, 10:46am, Matthias Kopfermann wrote:
} Subject: pipelines and &&
}
} I would very much like to know how sublists and pipelines are done:
} I read the following without understanding how to do it:
} 
} "If two pipelines are separated by ``&&'', the second
} pipeline is executed only if the first is successful

The real confusion comes from this text:

    A "pipeline" is a sequence of one or more commands separated by `|' or
    `|&'.  `|&' is shorthand for `2>&1 |'.  The standard output of each
    command is connected to the standard input of the next command in the
    pipeline.

How can one command be separated by `|' or `|&'?

That paragraph goes on to say:

               If a pipeline is preceded by `coproc', it is executed as a
    coprocess; a two-way pipe is established between it and the parent
    shell.  The shell can read from or write to the coprocess by means of
    the `>&p' and `<&p' redirection operators.  The value of a pipeline is
    the value of the last command.  If a pipeline is not preceded by `!',
    the value of that pipeline is the logical `NOT' of the value of the
    last command.

That's not just confusing, it's wrong (extra `not' in the last sentence).

Better text (I don't have the yodl doc handy to make a patch):

    A "pipeline" is either a simple command, or a sequence of two or more
    simple commands where each command is separated from the next by `|'
    or `|&'.  The standard output of each command is connected to the
    standard input of the next.  `|&' is shorthand for `2>&1 |' which
    connects both the standard output and the standard error of the
    command to the standard input of the next.  The value of a pipeline
    is the value of the last command, unless the pipeline is preceded by
    `!' in which case the value is the logical `NOT' of the value of the
    last command.

    If a pipeline is preceded by `coproc', it is executed as a coprocess;
    a two-way pipe is established between it and the parent shell.  The
    shell can read from or write to the coprocess by means of the `>&p'
    and `<&p' redirection operators or with `print -p' and `read -p'.  A
    pipeline cannot be preceded by both `coproc' and `!'.

Might as well fix the rest, too, though it's not as bad:

    A "sublist" is either a single pipeline, or a sequence of two or more
    pipelines separated by `&&' or `||'.  If two pipelines are separated
    by `&&', the second pipeline is executed only if the first succeeds
    (returns a zero value).  If two pipelines are separated by `||', the
    second is executed only if the first fails (returns a nonzero value).
    Both operators have equal precedence and are left associative.

    A "list" is a sequence of zero or more sublists, in which each sublist
    is terminated by `;', `&', `&|', `&!', or a newline.  This terminator
    may optionally be omitted from the last sublist in the list when the
    list appears as a complex command inside `(' `)' or `{' `}'.  When a
    sublist is terminated by `;' or newline, the shell waits for it to
    finish before executing the next sublist.  If a sublist is terminated
    by a `&', `&|', or `&!', the shell executes it in the background, and
    does not wait for it to finish.

Note that I've replaced the term "list" with "sublist" in a couple of key
places in the text above.  The original paragraph implies that e.g.
	sleep 10 ; echo hello &
will background the entire list; that's incorrect -- the sleep completes
before the echo is backgrounded.  This is the same as bash, but not the
same as csh (I'm not sure about ksh).

I'd consider moving the stuff about optionally omitting the terminator to
the sections about ( LIST ) and { LIST } under Complex Commands, and not
even mention omission of terminators in the section on simple commands.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


  parent reply	other threads:[~1998-05-25 16:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-25  9:46 Matthias Kopfermann
1998-05-25 10:36 ` Thomas Koehler
1998-05-26 18:01   ` Matthias Kopfermann
1998-05-26 19:38     ` Bart Schaefer
1998-05-25 16:38 ` Bart Schaefer [this message]
1998-05-25 10:46 John Riddoch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=980525093801.ZM13568@candle.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=matthi@finlandia.Infodrom.North.DE \
    --cc=zsh-users@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).