color codes to eval

color codes to eval

[Ray Andrews]

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


var="${red}howdy${nrm}"    # '$(red}' is just a color code, no problem 
there.
print -l $var
eval "print -l $var"

... shows:

howdy
(eval):1: bad pattern: ^[[31

... Is there a way to feed color codes to eval?  Seems to me I remember 
that there's some ${(?) var} ... some flag in there that does it.

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

Re: color codes to eval

[Lawrence Velázquez]

On Wed, Apr 10, 2024, at 12:46 PM, Ray Andrews wrote:
> var="${red}howdy${nrm}"    # '$(red}' is just a color code, no problem there.
> print -l $var
> eval "print -l $var"
>
> ... shows:
>
> howdy   
> (eval):1: bad pattern: ^[[31
>
> ... Is there a way to feed color codes to eval?

The issue is not "color codes" per se.  It's the fact that (assuming
ECMA-48 sequences) you're assembling and evaluating a command that
contains a word with an unquoted, unpaired "[" character, which zsh
deems to be an invalid glob (by default).  It's no different from:

	% print a[b
	zsh: bad pattern: a[b


> Seems to me I remember 
> that there's some ${(?) var} ... some flag in there that does it.

There are a number of possible solutions.

	# Avoid the pointless eval in the first place.
	print -l $var

	# Delay all expansions.
	eval 'print -l $var'

	# Delay the problematic expansion only.
	eval "print -l \$var"

	# Delay learning how quoting actually works.
	eval "print -l ${(q)var}"

	# Leave invalid patterns in the command.
	unsetopt BAD_PATTERN
	eval "print -l $var"


-- 
vq

Re: color codes to eval

[Andreas Kähäri]

On Wed, Apr 10, 2024 at 02:39:45PM -0400, Lawrence Velázquez wrote:
> On Wed, Apr 10, 2024, at 12:46 PM, Ray Andrews wrote:
> > var="${red}howdy${nrm}"    # '$(red}' is just a color code, no problem there.
> > print -l $var
> > eval "print -l $var"
> >
> > ... shows:
> >
> > howdy   
> > (eval):1: bad pattern: ^[[31
> >
> > ... Is there a way to feed color codes to eval?
> 
> The issue is not "color codes" per se.  It's the fact that (assuming
> ECMA-48 sequences) you're assembling and evaluating a command that
> contains a word with an unquoted, unpaired "[" character, which zsh
> deems to be an invalid glob (by default).  It's no different from:
> 
> 	% print a[b
> 	zsh: bad pattern: a[b
> 
> 
> > Seems to me I remember 
> > that there's some ${(?) var} ... some flag in there that does it.
> 
> There are a number of possible solutions.
> 
> 	# Avoid the pointless eval in the first place.
> 	print -l $var
> 
> 	# Delay all expansions.
> 	eval 'print -l $var'
> 
> 	# Delay the problematic expansion only.
> 	eval "print -l \$var"
> 
> 	# Delay learning how quoting actually works.
> 	eval "print -l ${(q)var}"
> 
> 	# Leave invalid patterns in the command.
> 	unsetopt BAD_PATTERN
> 	eval "print -l $var"
> 
> 
> -- 
> vq

They could also use print with -P and start using the prompt escape
%F{red}, but that's bypassing the issue rather than handling the
original string.

-- 
Andreas (Kusalananda) Kähäri
Uppsala, Sweden

.

Re: color codes to eval

[Ray Andrews]

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



On 2024-04-10 12:05, Andreas Kähäri wrote:
> They could also use print with -P and start using the prompt escape
> %F{red}, but that's bypassing the issue rather than handling the
> original string.
Yeah, the eval is buried under three nested levels of called functions, 
if it was directly on the command line there'd be no problem.




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

Re: color codes to eval

[Ray Andrews]

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



On 2024-04-10 11:39, Lawrence Velázquez wrote:
> # Avoid the pointless eval in the first place.
> 	print -l $var
The problem occurs in a deeper context where the eval can't be avoided, 
I just extracted the minimal example.
> 	# 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?
> 	# 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.  As to learning, 
that's what I'm trying to do.  Coming from DOS, the rules there are very 
different -- there's no preprocessing by the shell, command tails are 
passed to commands exactly as they are written.  It takes time to 
unlearn that.  It's almost hard coded into my brain.
> 	# Leave invalid patterns in the command.
> 	unsetopt BAD_PATTERN
> 	eval "print -l $var"
Looks dangerous!  Looks like bad practice.  But I'll experiment with it.

But:" # Delay all expansions. eval 'print -l $var' ... looks like the 
proper answer. Thanks Lawrence.

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

Re: color codes to eval

[Lawrence Velázquez]

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

Re: color codes to eval

[Ray Andrews]

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



On 2024-04-10 17:01, Lawrence Velázquez wrote:
> 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.
Ah!  Yes, I've run aground on those rocks too.  What would have served 
me well, and avoided the majority of my questions here, is some Big Book 
of Shell Gotchas.  Especially useful for a guy like me coming from DOS 
and only having that, and C, as my notions of what programming 
environments are like.  What's frustrating is that I learn something and 
six months latter I've forgotten.  I sure wish we could scan the 
archives, I'd be going back and checking my own previous questions -- 
like just now, I knew I'd asked about '(q)' previously.
> If you can avoid it, you might as well.  (Especially if you don't
> have a clear idea of what it does.)
I don't!  All I know is that it got me into trouble.
> 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.
>
Yeah who needs that, when we have a proper fix above.

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