Re: grammar triviality with '&&'

[Ray Andrews <rayandrews@eastlink.ca>]

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.