Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: grammar triviality with '&&'

On 03/05/2015 08:59 PM, Bart Schaefer wrote:
On Mar 4,  9:12am, Ray Andrews wrote:
} If an extra degree of freedom and capability was possible, and IF it
} could be implemented with no gotchas, then why not?

Because we don't need the grammar to become any more ad-hoc than it
already has?

A quite sufficient reason. My very unlearned sense of it was that the errorlevel test is implicit in any '&&' anyway, and since that test wraps 'down' legally already, then it would be trivially simple to understand that that same value is
grabbed when '&&' starts a line.  I was liking Vincent's thinking.

Or not!  It seemed to me like a relaxation of
something arbitrary. However if it really would be add-hoc then of course it
can't be touched.  Please recall that this is a *question*.

Back in the depths of time, one of the reasons zsh was invented was
because csh's grammar was too irregular.  Csh scripts originally (I
can't speak for how tcsh &c. may be now) could in fact be interpreted
one line at a time, and literally were:  "while" loop was processed by
remembering the file position of the string "while" and then when the
"end" was encountered, seeking back and re-reading the lines again.
This made it possible to write some really entertaining scripts that
edited their own code on the fly, but made it impossible to syntax
check a multi-line control structure before beginning to execute it.

God forbid.

The Bourne-shell / POSIX shell grammar is at least regular enough to
be parsed before it is executed, even with all its other warts.
Introducing a case where the command to the left of && / || can be
empty if and only if the conjunction is the first token on a line, is
the kind of irregularity that should be avoided.

Further, in the standard definition of the grammar where pipelines
separated by && or || form a sublist, the terminator that follows is
syntactically significant to the whole sublist.  That is:

	one && two || three &

is parsed as

	{ one && two || three } &

which is not the same as

	one ; [[ $? = 0 ]] && two ; [[ $? = 0 ]] || three &

Well that kills my notion that it's implicit, I thought the latter was what was really going
on in any case.  Dare a mortal ask what the difference is between those?

The deeper
question is why shells were designed this way. In C this sort of obscurity not only doesn't exist, it couldn't exist, you can wrap code anyway you want (string printing excepted). But shells are written in C, yet the decision was made to make things so convoluted that no one fully understands them. This work was done by geniuses so
there musta been a good reason.

Messages sorted by: Reverse Date, Date, Thread, Author