zsh-users
 help / color / mirror / code / Atom feed
From: Ray Andrews <rayandrews@eastlink.ca>
To: zsh-users@zsh.org
Subject: Re: trivial question
Date: Mon, 5 Dec 2022 06:11:53 -0800	[thread overview]
Message-ID: <1a9012ef-7bac-aae8-8a7c-5b8aa86b4cfa@eastlink.ca> (raw)
In-Reply-To: <8fc6bf49-3463-4432-b706-15b49d19a9b5@app.fastmail.com>


On 2022-12-04 22:40, Lawrence Velázquez wrote:
> It's common enough to forget (or not know) that globs support bracket
> expressions.

It's one of those gotchas that baffle the apprentice.  In practice I'd 
not leave the string unquoted, but  I'm glad to have my curiosity 
satisfied as to what's going on when it's unquoted. Good example of the 
'always quote' maxim in action.  Unless of course you have some specific 
reason to do otherwise.  I need a better gut understanding of when zsh 
is going to attempt one of these filename generations, it's naively 
'obvious' that 'echo var[2]' is a command to echo a string not look for 
a filename. With variables of course it's explicit with the dollar sign 
that one is requesting an expansion, but with files it's up to zsh when 
and where it wants a string to be a string and when it wants it to be a 
filename glob.  I myself would have made that explicit too. Then again, 
the shells started out processing filenames not strings, so it's 
understandable that things are as they are.  As I said it's a point of 
curiosity not practical difficulty.

 > That was a demonstration of behavior, not a suggestion to disable

And taken as such.

You really need to get out of the habit of enabling/disabling options
> that you don't understand just because one of us explains how they
> change some behavior or other.  You did the same thing with ERR_EXIT
> in users/28432, and it was equally misguided.
>
> The correct remedy here, as usual, is to quote properly, not fiddle
> with options.

I experiment with things, that's all.  One can take it on faith that 
ERR_EXIT is a bad idea, but when one watches it nuke a terminal one 
knows first hand that it's a bad idea.  It's much easier to remember 
from experience than by rote.  The nice thing about software is that one 
can experiment quite wildly without really doing any harm that a restart 
won't fix.  Obviously there are limitations to that, but still one has 
considerable latitude. It has always driven my teachers mad, but I learn 
by breaking things.  I like to Know with a kapital K.  Thanks for the 
demo code, that's a master class.





  reply	other threads:[~2022-12-05 14:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05  2:05 Ray Andrews
2022-12-05  2:52 ` Lawrence Velázquez
2022-12-05  5:20   ` Ray Andrews
2022-12-05  6:40     ` Lawrence Velázquez
2022-12-05 14:11       ` Ray Andrews [this message]
2022-12-06  2:12         ` Lawrence Velázquez
2022-12-06  2:29           ` Ray Andrews
2022-12-06  4:29             ` Bart Schaefer
2022-12-06  6:08               ` Lawrence Velázquez
2022-12-06 10:18               ` Roman Perepelitsa
2022-12-06 11:21                 ` Peter Stephenson
2022-12-06 15:28               ` Ray Andrews
2022-12-06 18:53                 ` Bart Schaefer
2022-12-07  0:02                 ` Lawrence Velázquez

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=1a9012ef-7bac-aae8-8a7c-5b8aa86b4cfa@eastlink.ca \
    --to=rayandrews@eastlink.ca \
    --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).