* trap question @ 2022-11-25 18:35 Ray Andrews 2022-11-25 18:57 ` Roman Perepelitsa 0 siblings, 1 reply; 11+ messages in thread From: Ray Andrews @ 2022-11-25 18:35 UTC (permalink / raw) To: Zsh Users 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-25 18:35 trap question Ray Andrews @ 2022-11-25 18:57 ` Roman Perepelitsa 2022-11-25 23:25 ` Ray Andrews 0 siblings, 1 reply; 11+ messages in thread From: Roman Perepelitsa @ 2022-11-25 18:57 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-25 18:57 ` Roman Perepelitsa @ 2022-11-25 23:25 ` Ray Andrews 2022-11-26 1:57 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Ray Andrews @ 2022-11-25 23:25 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-25 23:25 ` Ray Andrews @ 2022-11-26 1:57 ` Bart Schaefer 2022-11-26 4:25 ` Philippe Altherr 2022-11-26 4:27 ` Ray Andrews 0 siblings, 2 replies; 11+ messages in thread From: Bart Schaefer @ 2022-11-26 1:57 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-26 1:57 ` Bart Schaefer @ 2022-11-26 4:25 ` Philippe Altherr 2022-11-26 4:27 ` Ray Andrews 1 sibling, 0 replies; 11+ messages in thread From: Philippe Altherr @ 2022-11-26 4:25 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users, Bart Schaefer [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-26 1:57 ` Bart Schaefer 2022-11-26 4:25 ` Philippe Altherr @ 2022-11-26 4:27 ` Ray Andrews 2022-11-26 4:49 ` Lawrence Velázquez 2022-11-26 4:50 ` Bart Schaefer 1 sibling, 2 replies; 11+ messages in thread From: Ray Andrews @ 2022-11-26 4:27 UTC (permalink / raw) To: zsh-users 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-26 4:27 ` Ray Andrews @ 2022-11-26 4:49 ` Lawrence Velázquez 2022-11-26 4:50 ` Bart Schaefer 1 sibling, 0 replies; 11+ messages in thread From: Lawrence Velázquez @ 2022-11-26 4:49 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-26 4:27 ` Ray Andrews 2022-11-26 4:49 ` Lawrence Velázquez @ 2022-11-26 4:50 ` Bart Schaefer 2022-11-26 15:03 ` Ray Andrews 1 sibling, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2022-11-26 4:50 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-26 4:50 ` Bart Schaefer @ 2022-11-26 15:03 ` Ray Andrews 2022-11-26 15:25 ` Roman Perepelitsa 0 siblings, 1 reply; 11+ messages in thread From: Ray Andrews @ 2022-11-26 15:03 UTC (permalink / raw) To: zsh-users [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-26 15:03 ` Ray Andrews @ 2022-11-26 15:25 ` Roman Perepelitsa 2022-11-27 1:49 ` Ray Andrews 0 siblings, 1 reply; 11+ messages in thread From: Roman Perepelitsa @ 2022-11-26 15:25 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: trap question 2022-11-26 15:25 ` Roman Perepelitsa @ 2022-11-27 1:49 ` Ray Andrews 0 siblings, 0 replies; 11+ messages in thread From: Ray Andrews @ 2022-11-27 1:49 UTC (permalink / raw) To: zsh-users On 2022-11-26 07:25, Roman Perepelitsa wrote: > > There are no exceptions to this rule. I think I understand it now. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-11-27 1:50 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-25 18:35 trap question Ray Andrews 2022-11-25 18:57 ` Roman Perepelitsa 2022-11-25 23:25 ` Ray Andrews 2022-11-26 1:57 ` Bart Schaefer 2022-11-26 4:25 ` Philippe Altherr 2022-11-26 4:27 ` Ray Andrews 2022-11-26 4:49 ` Lawrence Velázquez 2022-11-26 4:50 ` Bart Schaefer 2022-11-26 15:03 ` Ray Andrews 2022-11-26 15:25 ` Roman Perepelitsa 2022-11-27 1:49 ` Ray Andrews
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).