trap question

trap question

[Ray Andrews]

This script:

typeset -g var=0
test1 ()
{
trap " [[ $var == '0' ]] && echo trap: var is: $var" EXIT
var=0
return
}
test2 ()
{
var=1
test1
echo "test2: var is: $var"
}

run:

$ . test1; test1; test2
trap: var is: 0
test2: 0

... I'm puzzled, even tho test2 does reset the variable to '1', test1 
sets it back to '0' just as the final 'echo' reports so I'm expecting 
the trap to spring.  Foolishly since that's C thinking whereas in 
interpreted code the value of the variable *at the time of the 
definition of the trap* is what is in effect and in this case that's 
'1'.  So what I'm really wanting is some way to set the trap in such a 
way that it responds to the value of 'var' *at the time of the springing 
of the trap*, namely at 'return'.  Can it be done?

Re: trap question

[Roman Perepelitsa]

On Fri, Nov 25, 2022 at 7:36 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> So what I'm really wanting is some way to set the trap in such a
> way that it responds to the value of 'var' *at the time of the springing
> of the trap*, namely at 'return'.  Can it be done?

Try replacing this:

    trap " [[ $var == '0' ]] && echo trap: var is: $var" EXIT

with this:

    trap ' [[ $var == 0 ]] && echo trap: var is: $var' EXIT

Roman.

Re: trap question

[Ray Andrews]

On 2022-11-25 10:57, Roman Perepelitsa wrote:
> Try replacing this:
>      trap " [[ $var == '0' ]] && echo trap: var is: $var" EXIT
>
> with this:
>
>      trap ' [[ $var == 0 ]] && echo trap: var is: $var' EXIT
>
Bullseye.  And I understand it I think.  Double quotes evaluated when 
parsed, single quotes kept as literal until trap is sprung, yes?  It 
wouldn't have occurred to me since I'd have expected the '$var' to 
remain un-expandable within single quotes.  Is this an exception or 
somehow to be viewed as routine?  BTW, will this trap catch exiting 
errors or just proper returns?  I know it doesn't catch ^C.

Re: trap question

[Bart Schaefer]

On Fri, Nov 25, 2022 at 3:25 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Double quotes evaluated when
> parsed, single quotes kept as literal until trap is sprung, yes?

Yes.

> wouldn't have occurred to me since I'd have expected the '$var' to
> remain un-expandable within single quotes.  Is this an exception or
> somehow to be viewed as routine?

You can think of "trap" as a delayed "eval".

> BTW, will this trap catch exiting
> errors or just proper returns?

Depends on the error.  If you have "setopt err_exit" (or err_return)
then the trap will be tripped when something returns false, but if you
have "setopt no_unset" (or use ${varname?message}) and reference a
variable that isn't set, the trap will not trip.  There are also some
circumstances where the parent shell will have done an opportunistic
"exec" of the final external command, so there's no zsh left to run
the trap (this is technically a bug, and will eventually get fixed).

Re: trap question

[Philippe Altherr]

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

>
> You can think of "trap" as a delayed "eval".


The thing that you have to understand is that your string gets
evaluated/expanded twice: once when the trap statement is evaluated and
once each time the EXIT trap is triggered.

With your original code, when the trap statement is evaluated, the first
argument of trap (your string) gets expanded, like it would be for any
other command. This yields the string  [[ 0 == '0' ]] && echo trap: var is:
0. The trap command records this string as the new command to execute for
future EXIT traps. Thus, when an EXIT trap triggers, it will obviously
always print 0 rather than the current value of the variable "var".

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


On Sat, Nov 26, 2022 at 2:58 AM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Fri, Nov 25, 2022 at 3:25 PM Ray Andrews <rayandrews@eastlink.ca>
> wrote:
> >
> > Double quotes evaluated when
> > parsed, single quotes kept as literal until trap is sprung, yes?
>
> Yes.
>
> > wouldn't have occurred to me since I'd have expected the '$var' to
> > remain un-expandable within single quotes.  Is this an exception or
> > somehow to be viewed as routine?
>
> You can think of "trap" as a delayed "eval".
>
> > BTW, will this trap catch exiting
> > errors or just proper returns?
>
> Depends on the error.  If you have "setopt err_exit" (or err_return)
> then the trap will be tripped when something returns false, but if you
> have "setopt no_unset" (or use ${varname?message}) and reference a
> variable that isn't set, the trap will not trip.  There are also some
> circumstances where the parent shell will have done an opportunistic
> "exec" of the final external command, so there's no zsh left to run
> the trap (this is technically a bug, and will eventually get fixed).
>
>

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

Re: trap question

[Ray Andrews]

On 2022-11-25 17:57, Bart Schaefer wrote:
> remain un-expandable within single quotes. Is this an exception or
>> somehow to be viewed as routine?
> You can think of "trap" as a delayed "eval".
Ok, so I can continue to expect that there's no expansions within single 
quotes.  It's sorta intuitive that a trap is a special case.
>
>> BTW, will this trap catch exiting
>> errors or just proper returns?
> Depends on the error.  If you have "setopt err_exit" (or err_return)
> then the trap will be tripped when something returns false,

I have that off by default, sounds like it should be on.  Thing is that 
this is for a function that uses zcurses and if it quits before cleaning 
up after itself ...  it's quite remarkable how many different things 
might go wrong when zcurses still wants to be in charge.  So I'm hoping 
the trap -- which does all the cleanup -- will be sprung after any 
internal error as well as controlled exits.  Mind that's luxurious if it 
can do it, I know how to mop up elsewise.

BTW, speaking of zcurses, I see nothing in the doc, but is there a way 
to list open windows?

Re: trap question

[Lawrence Velázquez]

On Fri, Nov 25, 2022, at 11:27 PM, Ray Andrews wrote:
> On 2022-11-25 17:57, Bart Schaefer wrote:
>> remain un-expandable within single quotes. Is this an exception or
>>> somehow to be viewed as routine?
>> You can think of "trap" as a delayed "eval".
> Ok, so I can continue to expect that there's no expansions within single 
> quotes.  It's sorta intuitive that a trap is a special case.

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

-- 
vq

Re: trap question

[Bart Schaefer]

On Fri, Nov 25, 2022 at 8:27 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-11-25 17:57, Bart Schaefer wrote:
> > Depends on the error.  If you have "setopt err_exit" (or err_return)
> > then the trap will be tripped when something returns false,
>
> I have that off by default, sounds like it should be on.

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.

Re: trap question

[Ray Andrews]

[-- 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 --]

Re: trap question

[Roman Perepelitsa]

On Sat, Nov 26, 2022 at 4:04 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> 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?

There are no exceptions to this rule. The content enclosed in single
quotes never undergoes parameter expansion, command substitution or
arithmetic expansion: $ stays $. Now, what you are going to do with
the *value* that results from the evaluation of a single-quoted
literal is up to you. You can certainly decide to perform those
expansions.

    foo='$(echo hello)'
    some-command "$foo"

The first line doesn't expand $(echo hello) but the second command
might. Maybe this command passes the argument to trap, eval, print -P,
${(e)1}, etc. The command doesn't care whether the argument was
created by enclosing something in single quotes and in fact has no way
of knowing this. It only sees the value but not the providence of it.

    foo="\$(echo hello)"
    some-command "$foo"

This second snippet is exactly identical to the first. The command
will receive the same argument and won't be able to tell the
difference.

Roman.

Re: trap question

[Ray Andrews]

On 2022-11-26 07:25, Roman Perepelitsa wrote:
>
> There are no exceptions to this rule.
I think I understand it now.