Re: color codes to eval

[Lawrence Velázquez <larryv@xxxxxxx>]

On Wed, Apr 10, 2024, at 3:12 PM, Ray Andrews wrote:
> On 2024-04-10 11:39, Lawrence Velázquez wrote:
>> 	# Delay all expansions.
>> 	eval 'print -l $var'
> Works!  And I believe I understand it.  '$var' *will* expand even though it doesn't look like it, because eval takes a second crack at the line after the single quotes are removed, yes?

That's right.  And since you're not using $~var or GLOB_SUBST, the
result of that delayed expansion will be used literally instead of
as a pattern for filename generation.


>> 	# Delay learning how quoting actually works.
>> 	eval "print -l ${(q)var}"
> I'll play with that further, that's the thing I was trying to remember.  First efforts are not working, but I do recall that '(q)' ended up giving me trouble down the line and was best avoided.

If you can avoid it, you might as well.  (Especially if you don't
have a clear idea of what it does.)


>> 	# Leave invalid patterns in the command.
>> 	unsetopt BAD_PATTERN
>> 	eval "print -l $var"
> Looks dangerous!  Looks like bad practice.

It's usually not what you want, since it may let typos and other
mistakes go by quietly.  It's generally easy enough to handle
troublesome non-patterns by quoting them or using them through
variables.

NO_BAD_PATTERN does align more closely with POSIX and other shells
and is the behavior used in sh/ksh emulation.

	% script='echo a[b'
	% bash -c $script
	a[b
	% dash -c $script
	a[b
	% ksh -c $script
	a[b
	% mksh -c $script
	a[b
	% yash -c $script
	a[b
	% zsh -c $script
	zsh:1: bad pattern: a[b
	% zsh +o BAD_PATTERN -c $script
	a[b


-- 
vq