zsh-users
 help / color / mirror / code / Atom feed
From: Ray Andrews <rayandrews@eastlink.ca>
To: Kurtis Rader <krader@skepticism.us>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: grammar triviality with '&&'
Date: Mon, 02 Mar 2015 08:17:42 -0800	[thread overview]
Message-ID: <54F48D26.6040303@eastlink.ca> (raw)
In-Reply-To: <CABx2=D9sJAaZuCVnUDTbi=KS6v42EDn28Xv0gtJNA_AsLiD74Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

On 03/01/2015 09:22 PM, Kurtis Rader wrote:
>
> One obvious cost is that anyone reading a script that uses the feature 
> will naturally assume the author made a mistake and the script is 
> invalid.

So don't use it if, when or where tradition trumps practicality--which 
is almost everywhere.
> The reason this restriction exists is not arbitrary.

That may very well be the case, which is why I raised the question, but 
it seems that it might not be the case after all (Lawrence). I'm over 
fascinated by this sort of minutia.
> It is a an obvious and natural consequence of how the grammar was 
> interpreted by the person(s) who wrote the code for the Bourne-shell, 
> Bash, Zsh, etcetera. Why is it simpler for the code to "just grab the 
> errorlevel of the previous command"  when it sees a leading "&&" or "||"?

But is that not what it already does?  The question is whether a line 
break or a semi *necessarily* prevents that.  IOW, what ambiguity would 
this cause:

[ -e file1 ]
&& [ -e file2 ]
> Also, it is not just a matter of changing the zsh implementation. Unit 
> tests need to be added and existing tests likely updated. 
> Documentation needs to be changed. Whether the change might break 
> existing uses has to be carefully considered.

Absolutely, and that is probably reason enough why it won't happen. It 
would have to be nothing more than a relaxation of an arbitrary rule ( 
**if** it is arbitrary)--maybe there is a very good reason why 
errorlevel can't be passed beyond a newline or semi.  If there is such a 
good reason, I'd be educated to learn what it is.  But since "[[ $? -eq 
0 ]]" works past the newline, at this point I can't see what the 
linewrap would *necessarily* break.
>
> You say "I'd use it for sure". Please provide a non-contrived example, 
> preferably two or three, where this would be useful.

if [ -e 'shelly.txt' ]
&& [ -n "$ozymandias" ]
&& [ grep "I met a traveler" ]
then
   echo "Look on my works, ye mighty"
fi


... I have a trivial preference for that form, I find it neater. It is 
very unimportant.

> How hard is it to be explicit and include the "[[ $? -eq 0 ]]" in a 
> script? If this feature were truly useful for interactive use I might 
> agree with you. But I see no evidence and my 30+ years experience that 
> it has no use outside of making a tiny percentage of scripts a few 
> characters shorter.

Exactly so.  Whereas I'd like it for saving me the line continuation 
backslash, that is monumentally trivial, I'm interested in the theory of 
the thing.  I like Lawrence's thinking on the matter, however.

Don't take this more seriously than I take it.


  reply	other threads:[~2015-03-02 16:17 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-01 16:07 Ray Andrews
2015-03-01 16:43 ` ZyX
2015-03-01 17:01   ` Ray Andrews
2015-03-01 18:48     ` Bart Schaefer
2015-03-01 19:00       ` ZyX
2015-03-01 19:16       ` Ray Andrews
2015-03-01 20:48         ` ZyX
2015-03-01 18:49     ` Lawrence Velázquez
2015-03-02  2:27       ` Vincent Lefevre
2015-03-02  3:12         ` Ray Andrews
2015-03-02  5:22           ` Lawrence Velázquez
2015-03-02  3:53         ` Kurtis Rader
2015-03-02  4:18           ` Ray Andrews
2015-03-02  5:22             ` Kurtis Rader
2015-03-02 16:17               ` Ray Andrews [this message]
2015-03-02 18:52                 ` Kurtis Rader
2015-03-02 19:03                   ` ZyX
2015-03-02 20:16                     ` Kurtis Rader
2015-03-03  4:15                       ` ZyX
2015-03-03  4:43                         ` Kurtis Rader
2015-03-04 15:03                           ` Vincent Lefevre
2015-03-04 19:07                           ` ZyX
2015-03-02 19:25                   ` Ray Andrews
2015-03-02 10:46           ` Vincent Lefevre
2015-03-02 11:06             ` Peter Stephenson
2015-03-02 19:19               ` Bart Schaefer
2015-03-04 14:47                 ` Vincent Lefevre
2015-03-05  1:51                   ` Bart Schaefer
2015-03-05 10:06                     ` Peter Stephenson
2015-03-02  8:54         ` Bart Schaefer
2015-03-02 10:31           ` Vincent Lefevre
2015-03-02 16:31             ` Ray Andrews
2015-03-02 16:49             ` Bart Schaefer
2015-03-02 17:38               ` Ray Andrews
2015-03-02 18:51                 ` Bart Schaefer
2015-03-04  8:55               ` Vincent Lefevre
2015-03-04 17:12                 ` Ray Andrews
2015-03-06  4:59                   ` Bart Schaefer
2015-03-06 16:10                     ` Ray Andrews
2015-03-06 20:23                       ` Lawrence Velázquez
2015-03-06 21:25                         ` Ray Andrews
2015-03-06 16:32                     ` Vincent Lefevre
2015-03-06 17:43                       ` Bart Schaefer
2015-03-06 21:01                         ` Ray Andrews
2015-03-09 11:26                         ` Vincent Lefevre

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=54F48D26.6040303@eastlink.ca \
    --to=rayandrews@eastlink.ca \
    --cc=krader@skepticism.us \
    --cc=zsh-users@zsh.org \
    /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).