Re: trap question

[Ray Andrews <rayandrews@eastlink.ca>]

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


On 2022-11-25 20:50, Bart Schaefer wrote:
> No, it should not be on. I was giving an example of an error where an
> exit trap would be tripped, not implying that you want that condition
> to be an error.  If a command returning false is an error you should
> be explicitly handling that and doing a normal return/exit.
>
Eventually sure, but when things are unstable it's at least nice to have 
zcurses powered down under control, no?  I'll set that option and see 
what transpires.

	Lawrence:

	It's not a special case, just like "eval" isn't a special case.

I'd put it the other way: trap and eval are both special cases, no?  Surely the general rule is that nothing is ever expanded within single quotes?


Now, if you use single quotes instead of double quotes, the first 
argument of the trap command expands to the string [[ $var == '0' ]] && 
echo trap: var is: $var, which looks like a much more interesting 
command to execute when the EXIT trap triggers ;-)

Philippe

Ok, that makes nothing but sense.  The single quotes do what single 
quotes do, *but* there is also the intuitive way that the trap is always 
'in reserve' -- it never does anything when/where written, only when 
sprung, so at that time the quotes are gone and the variable expands to 
it's value in real time.  Got it.  It's sorta like compiled code.




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