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.
next prev parent 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).