Re: trivial question

[Lawrence Velázquez <larryv@xxxxxxx>]

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