Re: pipelines and &&

Re: pipelines and &&

[John Riddoch]

> 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 (returns a zero
> value).  If two pipelines are separated by ``||'', the second is
> executed only if the first is unsuccessful (returns a nonzero value).
> Both operators have equal precedence and are left associative."

This has nothing to do with pipes; the term is probably somewhat confusing.

A better example would be:

cp file file.bak || echo "file not backed up"

If the file could not be backed up (eg, the file does not exist or the user 
does not have write permission in the directory), then the error message is 
shown.  Alternatively:

cp file file.bak && echo "file backed up"

|| and && are alternatives to testing $?
eg:

cp file file.bak
if [ $? = 0 ]; then echo "file backed up"; done

is equivalent to the second example above.  However, || and && are shorter and 
can be slightly more understandable.

--
John Riddoch	Email: jr@scms.rgu.ac.uk	Telephone: (01224)262721
Room C6, School of Computer and Mathematical Science
Robert Gordon University, Aberdeen, AB25 1HG
And yeah, as I walk through the valley of the shadow of Death, I shall
fear no evil, 'cause I'm packing an M60 with explosive ammo.

pipelines and &&

[Matthias Kopfermann]

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 (returns a zero
value).  If two pipelines are separated by ``||'', the second is
executed only if the first is unsuccessful (returns a nonzero value).
Both operators have equal precedence and are left associative."

now i try something like:
	ls | wc && | less  (just to understand the mechanism)
      
		^       ^
	There are two pipelines 1) | wc
									2) | less
	They are separated by &&.
		Result: "zsh: parse error near `|'"

I seem to do it wrong.
could you give some examples here?

Re: pipelines and &&

[Thomas Koehler]

On Mon, May 25, 1998 at 11:46:00AM +0200, Matthias Kopfermann wrote:

> 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 (returns a zero
> value).  If two pipelines are separated by ``||'', the second is
> executed only if the first is unsuccessful (returns a nonzero value).
> Both operators have equal precedence and are left associative."
> 
> now i try something like:
> 	ls | wc && | less  (just to understand the mechanism)
>       
> 		^       ^
> 	There are two pipelines 1) | wc
> 									2) | less
> 	They are separated by &&.
> 		Result: "zsh: parse error near `|'"
> 
> I seem to do it wrong.
> could you give some examples here?

Try something like this:

ls -al | more && cat ~/.zshrc | grep setopt

Now if you're done with pipeline 1 ( ls -al | more ), its exit status
says whether or not to run pipeline 2 (cat ~/.zshrc | grep setopt).
If you kill the "more" process (so it doesn't exit with code 0), the
second pipeline will not be executed.

HTH,
Thomas

-- 
    Thomas Köhler    Email:     jean-luc@picard.franken.de
        <><           WWW:    http://home.pages.de/~jeanluc/
                      IRC:               jeanluc
      LCARS --- Linux for Computers on All Real Starships

Re: pipelines and &&

[Matthias Kopfermann]

> 
> Try something like this:
> 
> ls -al | more && cat ~/.zshrc | grep setopt

disappointing! i thought that was a unique zsh-feature which did
not work because i was doing something wrong.
the above is well known to me :)

Re: pipelines and &&

[Bart Schaefer]

On May 26,  8:01pm, Matthias Kopfermann wrote:
} Subject: Re: pipelines and &&
}
} disappointing! i thought that was a unique zsh-feature which did
} not work because i was doing something wrong.

What, exactly, would you expect it to do?

Your original example was

	ls | wc && | less

The closest thing I can imagine to what that might mean is equivalent to

	coproc cat
	ls >&p | wc && less <&p

which doesn't quite work right because the coproc doesn't exit after
"ls" finishes writing to it, but gives you the idea.

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

Re: pipelines and &&

[Bart Schaefer]

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