trivial question

trivial question

[Ray Andrews]

Running this:

var=( "now is" "the time" "for all good" "men to" )

echo var[2] ain\'t nothing
echo var2] ain\'t nothing
echo "var[2]"
echo $var[2]

... I get this:

4 /aWorking/Zsh/Source/Wk 0 $ . test1
ain't nothing
var2] ain't nothing
var[2]
the time


... It hardly matters but I'm curious that 'var[2]' without the dollar 
sign evaluates to nothing at all.  I have zero need for it to do 
otherwise still I'm mildly expecting it to just end up as a plain string 
the same way 'var2]' does.  Seems strange that it evaporates entirely.

Re: trivial question

[Lawrence Velázquez]

On Sun, Dec 4, 2022, at 9:05 PM, Ray Andrews wrote:
> Running this:
>
> var=( "now is" "the time" "for all good" "men to" )
>
> echo var[2] ain\'t nothing
> echo var2] ain\'t nothing
> echo "var[2]"
> echo $var[2]
>
> ... I get this:
>
> 4 /aWorking/Zsh/Source/Wk 0 $ . test1
> ain't nothing
> var2] ain't nothing
> var[2]
> the time
>
>
> ... It hardly matters but I'm curious that 'var[2]' without the dollar 
> sign evaluates to nothing at all.

In this context, "var[2]" is recognized as a valid glob, and zsh
attempts to generate filenames with it.  If a file or directory
matches, its name is inserted as usual.

	% cat foo.zsh
	var=('now is' 'the time' 'for all good' 'men to')

	printf '<%s>' var[2] ain\'t nothing
	echo

	% : >var2
	% zsh foo.zsh
	<var2><ain't><nothing>

If no file or directory matches, zsh generates an error by default.

	% rm var2
	% zsh foo.zsh
	foo.zsh:3: no matches found: var[2]

If NULL_GLOB is enabled (which you presumably have done), the failed
glob expands to nothing instead.

	% zsh -o NULL_GLOB foo.zsh
	<ain't><nothing>


> I have zero need for it to do 
> otherwise still I'm mildly expecting it to just end up as a plain string

This happens if NOMATCH is disabled.

	% zsh +o NOMATCH foo.zsh  
	<var[2]><ain't><nothing>

It is also the default behavior for failed globs in other shells.


> the same way 'var2]' does.

The latter is not a valid glob, so zsh does not attempt to generate
filenames with it.  It is just passed as a literal argument.


> Seems strange that it evaporates entirely.

This is all explained in the manual.

https://zsh.sourceforge.io/Doc/Release/Expansion.html#Filename-Generation


-- 
vq

Re: trivial question

[Ray Andrews]

On 2022-12-04 18:52, Lawrence Velázquez wrote:
> In this context, "var[2]" is recognized as a valid glob, and zsh
> attempts to generate filenames with it.  If a file or directory
> matches, its name is inserted as usual.
I see.  A file glob would be the last thing I'd be expecting, I'm 
expecting it to be a nothing but a string.  Anyway that's a clear 
explanation.

> % zsh +o NOMATCH foo.zsh
> 	<var[2]><ain't><nothing>
>
That works.  First experiments trying '(un)setopt NOMATCH' aren't 
working but now that I know what to chew on I'll bag it.
> This is all explained in the manual.
> https://zsh.sourceforge.io/Doc/Release/Expansion.html#Filename-Generation
>
>
Thanks, as is so often the case, it's not having a clue where to look 
that's that hard part.  I'd not have dreamed this was a filename 
generation issue.

Re: trivial question

[Lawrence Velázquez]

On Mon, Dec 5, 2022, at 12:20 AM, Ray Andrews wrote:
> On 2022-12-04 18:52, Lawrence Velázquez wrote:
>> In this context, "var[2]" is recognized as a valid glob, and zsh
>> attempts to generate filenames with it.  If a file or directory
>> matches, its name is inserted as usual.
> I see.  A file glob would be the last thing I'd be expecting, I'm 
> expecting it to be a nothing but a string.

It's common enough to forget (or not know) that globs support bracket
expressions.  Most unquoted uses like yours are incorrect and can
produce unexpected results if they actually match anything (as
unlikely as that might be).

	% var=(a b c)
	% var1=hello
	% unset var[1]
	zsh: no matches found: var[1]
	% typeset -p var var1
	typeset -a var=( a b c )
	typeset var1=hello
	% : >var1
	% unset var[1]       
	% typeset -p var var1
	typeset: no such variable: var1
	typeset -a var=( a b c )
	% unset 'var[1]'     
	% typeset -p var var1
	typeset: no such variable: var1
	typeset -a var=( '' b c )

See also: https://mywiki.wooledge.org/BashPitfalls#unset_a.5B0.5D


>> % zsh +o NOMATCH foo.zsh
>> 	<var[2]><ain't><nothing>
>>
> That works.  First experiments trying '(un)setopt NOMATCH' aren't 
> working but now that I know what to chew on I'll bag it.

That was a demonstration of behavior, not a suggestion to disable
NOMATCH.  Leaving unmatched globs intact is rarely what you want.

	% setopt NOMATCH NO_NULL_GLOB
	% touch nonexistent*
	zsh: no matches found: nonexistent*
	% ls
	% unsetopt NOMATCH
	% touch nonexistent*
	% ls
	nonexistent*

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.


-- 
vq

Re: trivial question

[Ray Andrews]

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.

Re: trivial question

[Lawrence Velázquez]

On Mon, Dec 5, 2022, at 9:11 AM, Ray Andrews wrote:
> I need a better gut understanding of when zsh 
> is going to attempt one of these filename generations

A decent starting point is to assume that unquoted punctuation is
special until you verify otherwise (assuming you don't actually
want the special behavior).  Even then you might as well quote it
to avoid confusing your future self.

> it's naively 
> 'obvious' that 'echo var[2]' is a command to echo a string not look for 
> a filename.

Presumably you've internalized that "*" is a globbing character,
so you wouldn't be confused if this printed a bunch of filenames:

    echo *.txt

Once you know that "[" is also a globbing character, it should cease
to be confusing.  That said, remembering all the globbing characters
can be a challenge, especially the ones you don't use regularly.

-- 
vq

Re: trivial question

[Ray Andrews]

On 2022-12-05 18:12, Lawrence Velázquez wrote:
> A decent starting point is to assume that unquoted punctuation is
> special until you verify otherwise (assuming you don't actually
> want the special behavior).  Even then you might as well quote it
> to avoid confusing your future self.
Sure, I quote almost everything anyway.
>
> Presumably you've internalized that "*" is a globbing character,
> so you wouldn't be confused if this printed a bunch of filenames:
>
>      echo *.txt

I may as well admit it: I didn't know you could do that.  Nuts, I just 
never  tried it.  One echo's strings.  And true to form:

$ echo no-such-file*

... returns nothing, just like my initial example.

>
> Once you know that "[" is also a globbing character, it should cease
> to be confusing.  That said, remembering all the globbing characters
> can be a challenge, especially the ones you don't use regularly.

Ok, this opens the door to clarity.  I just need to know when zsh is 
going to attempt globbing and keep on the watch for that.  * ? [] (but 
only paired!) what else?  Man!  To think that I'm just learning this 
now.  It's been an educational day.

Re: trivial question

[Bart Schaefer]

On Mon, Dec 5, 2022 at 6:29 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I just need to know when zsh is
> going to attempt globbing and keep on the watch for that.

The cases where it is going to perform globbing are more universal
than those where it is not.

This is back to the DOS vs. (unixy) shell thing.  The command name
generally doesn't matter.  "echo" is not what's deciding whether the
arguments that follow are glob patterns; the shell itself determines
that before it even knows what "echo" will do, and that's going to be
the case for every command.

The only places where that won't be true are for some things that are
actual syntax tokens rather than command names.

>  * ? [] (but only paired!) what else?

If you're asking what else are glob characters, you should probably
attempt to understand the corresponding manual section.

Re: trivial question

[Lawrence Velázquez]

On Mon, Dec 5, 2022, at 11:29 PM, Bart Schaefer wrote:
> On Mon, Dec 5, 2022 at 6:29 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>>
>> I just need to know when zsh is
>> going to attempt globbing and keep on the watch for that.
>
> The cases where it is going to perform globbing are more universal
> than those where it is not.
>
> This is back to the DOS vs. (unixy) shell thing.  The command name
> generally doesn't matter.  "echo" is not what's deciding whether the
> arguments that follow are glob patterns; the shell itself determines
> that before it even knows what "echo" will do, and that's going to be
> the case for every command.

You can observe this with XTRACE:

	% zsh -fxc 'echo [DM]*'
	+zsh:1> echo Desktop Documents Downloads Movies Music
	Desktop Documents Downloads Movies Music

The XTRACE output (the line beginning with "+zsh:1>") represents
the command that is actually executed.  Note that the glob has been
replaced by matching filenames.  The "echo" utility does not know
that those arguments were generated from a glob; you might as well
have typed them out by hand.

Compare and contrast with this, which does not use a glob:

	% zsh -fxc 'echo DM]'
	+zsh:1> echo 'DM]'
	DM]


-- 
vq

Re: trivial question

[Roman Perepelitsa]

On Tue, Dec 6, 2022 at 5:30 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The cases where it is going to perform globbing are more universal
> than those where it is not.

I know that filename generation is performed in these places:

- On words of a simple command.
- Within array initializers.
- Within for loop initializers.

You can also enable it in some places with (#q). Are there any other
places where filename generation takes place? I cannot find this in
the docs.

Roman.

Re: trivial question

[Peter Stephenson]

> On 06/12/2022 10:18 Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> On Tue, Dec 6, 2022 at 5:30 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > The cases where it is going to perform globbing are more universal
> > than those where it is not.
> 
> I know that filename generation is performed in these places:
> 
> - On words of a simple command.
> - Within array initializers.
> - Within for loop initializers.
> 
> You can also enable it in some places with (#q). Are there any other
> places where filename generation takes place? I cannot find this in
> the docs.

There's the special case of the GLOB_ASSIGN option where all
assignments, not just arrays, undergo globbing.  That's for
compatibility with early versions of zsh, otherwise it's very
confusing.

pws

Re: trivial question

[Ray Andrews]

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


On 2022-12-05 20:29, Bart Schaefer wrote:
>
> If you're asking what else are glob characters, you should probably
> attempt to understand the corresponding manual section.
>
If a word contains an unquoted instance of one of the characters ‘*’, 
‘(’, ‘|’, ‘<’, ‘[’, or ‘?’, it is regarded as a pattern for filename 
generation, unless the GLOB option is unset. If the EXTENDED_GLOB option 
is set, the ‘^’ and ‘#’ characters also denote a pattern; otherwise they 
are not treated specially by the shell.

What overloads me is the way pattern globbing (do we say that? or just 
call it 'pattern matching'?) and filename globbing are conflated in 
there.  So very similar but so subtly different. Anyway stuff is 
starting to stick to the inside of my skull.   At the very least I know 
where to expect trouble.  Obviously it's decades late to complain about 
any of this, but life would be simpler if it was explicit that one 
wanted to generate filenames or one wanted strings to be strings.  That 
way there'd be no need for a list of special characters. I know that 
echo doesn't decide how it's arguments will be handled, still it's 
intuitive that one echos a string.  But I suppose the rule is to quote 
anything you want to be immune to such expansions and it's as simple as 
that. Unquote and you're taking your chances.  Fair enough.  It's an 
early lesson.

Lawrence:

> You can observe this with XTRACE:

Gotta spend more time with that.  Output can be a bit overwhelming but slow and steady -- the information is in there.
A better tool is "typeset -p", which outputs an accurate (albeit
sometimes difficult-to-read) representation.

	% typeset -p arr
	typeset -a arr=( $'a\nb\C-Mc' $'d\C-Me\nf' )

Yes! It almost doesn't matter that it's hard to read, the point is to catch that one is not the same as the other.  Yup, that's a life-lesson.

Peter:

There's the special case of the GLOB_ASSIGN option where all
assignments, not just arrays, undergo globbing.  That's for
compatibility with early versions of zsh, otherwise it's very
confusing.

Deus absit.  What I might like is some way of turning it all off.  Like unsetopt glob, yes?  Actually, tho it started out as a purely academic question, I can now think of a place where I think I'll want to do that.



[-- Attachment #2: Type: text/html, Size: 3084 bytes --]

Re: trivial question

[Bart Schaefer]

On Tue, Dec 6, 2022 at 7:28 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> If a word contains an unquoted instance of one of the characters ‘*’, ‘(’, ‘|’, ‘<’, ‘[’, or ‘?’, it is regarded as a pattern for filename generation, unless the GLOB option is unset. If the EXTENDED_GLOB option is set, the ‘^’ and ‘#’ characters also denote a pattern; otherwise they are not treated specially by the shell.

[...]

> Deus absit.  What I might like is some way of turning it all off.  Like unsetopt glob, yes?

Yes?  Re-read the doc excerpt you quoted above?

Generally, though, you don't want to do that.  Instead you should use
the "noglob" precommand modifier, e.g.

% noglob echo var[2]

Re: trivial question

[Lawrence Velázquez]

On Tue, Dec 6, 2022, at 10:28 AM, Ray Andrews wrote:
> Lawrence:
>
> [...]
>
> A better tool is "typeset -p", which outputs an accurate (albeit
> sometimes difficult-to-read) representation.
>
> 	% typeset -p arr
> 	typeset -a arr=( $'a\nb\C-Mc' $'d\C-Me\nf' )

Please don't take material from one conversation and reply to it
in another conversation.  That makes both conversations more difficult
to follow and degrades the usefulness of MUA threading.

-- 
vq