* local but persistent integer? @ 2022-09-16 15:19 Ray Andrews 2022-09-16 17:44 ` Bart Schaefer 0 siblings, 1 reply; 6+ messages in thread From: Ray Andrews @ 2022-09-16 15:19 UTC (permalink / raw) To: Zsh Users This works in my function: if [ "$1" = "start" ]; then integer -x start="$(( $(date +%s%N)/1000000 ))" return fi if [ "$1" = "stop" ]; then start=0 return fi [[ $start == '0' ]] && echo "Timer not properly started" && return ... code ... I need 'start' to persist between function calls which it does but it would be nice if it could be local as well since it has no use outside this function. Also, it would be more hygienic to kill the variable entirely in case of 'stop' rather than set it to zero. I tried 'unset' but it didn't seem to work. This will be doable of course. Very minor issues but I'd like to be able to do it properly. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: local but persistent integer? 2022-09-16 15:19 local but persistent integer? Ray Andrews @ 2022-09-16 17:44 ` Bart Schaefer 2022-09-16 19:43 ` Ray Andrews 0 siblings, 1 reply; 6+ messages in thread From: Bart Schaefer @ 2022-09-16 17:44 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users On Fri, Sep 16, 2022 at 8:19 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > integer -x start="$(( $(date +%s%N)/1000000 ))" > > ... I need 'start' to persist between function calls which it does Given that construct, it should not. "integer -x" within a function puts something in the environment (so visible to external processes), but it's still scoped to the function and goes away when the function finishes. > I tried 'unset' but it didn't seem to work. That indicates that you're unsetting the local, but there must still be another global $start that came from somewhere. Use a more distinctive variable name (see below). > it would be nice if it could be local as well since it has no use > outside this function. Unfortunately the base model for shell variables (a form of dynamic scoping) and interpretive function invocation does not lend itself to the form of static scoping that you're hoping for. A second run of a function is just re-interpreting the function source code, not re-entering any existing scope other than the global one. Your best bet is to use something like integer -gH _myfn_start=$((....)) (( $_myfn_start == 0 )) && ... which will create a global variable whose value is concealed, using a name that only your function "knows about". This can be generalized with something like this (assumes proper option settings to make ${0} reflect the current function name): integer -gH _${0}_start=... (( ${(P)${:-_${0}_start}} == 0 )) && ... but that's probably overkill in your case. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: local but persistent integer? 2022-09-16 17:44 ` Bart Schaefer @ 2022-09-16 19:43 ` Ray Andrews 2022-09-16 21:41 ` Bart Schaefer 0 siblings, 1 reply; 6+ messages in thread From: Ray Andrews @ 2022-09-16 19:43 UTC (permalink / raw) To: zsh-users On 2022-09-16 10:44, Bart Schaefer wrote: > On Fri, Sep 16, 2022 at 8:19 AM Ray Andrews <rayandrews@eastlink.ca> wrote: >> integer -x start="$(( $(date +%s%N)/1000000 ))" >> >> ... I need 'start' to persist between function calls which it does > Given that construct, it should not. "integer -x" within a function > puts something in the environment (so visible to external processes), > but it's still scoped to the function and goes away when the function > finishes. I must be misunderstanding: #!/usr/bin/zsh function tt () { integer -x unique_to_tt=2 } 8 /aWorking/Zsh/Source/Wk 1 $ echo $unique_to_tt 8 /aWorking/Zsh/Source/Wk 1 $ . temp1; tt; echo $unique_to_tt 2 ... so it's visible externally as you say, but it's not going away either. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: local but persistent integer? 2022-09-16 19:43 ` Ray Andrews @ 2022-09-16 21:41 ` Bart Schaefer 2022-09-16 21:50 ` Ray Andrews 2022-09-17 1:51 ` Ray Andrews 0 siblings, 2 replies; 6+ messages in thread From: Bart Schaefer @ 2022-09-16 21:41 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Sep 16, 2022 at 12:43 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2022-09-16 10:44, Bart Schaefer wrote: > > On Fri, Sep 16, 2022 at 8:19 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > >> integer -x start="$(( $(date +%s%N)/1000000 ))" > >> > >> ... I need 'start' to persist between function calls which it does > > Given that construct, it should not. > > ... so it's visible externally as you say, but it's not going away either. Hm, this is possibly a bug, but it's also possibly an expected side-effect of "export" that I've forgotten about. My previous statement is correct for string-scalars created with "typeset" and "local" etc., but "integer" behaves differently. I think this is related to preserving the attributes of the variable (i.e., even if unset, it remains an integer, so if you assign to it again it acts like one) about which I believe I recall some discussion, but I don't recall when it was implemented. In any case it's not reliable to expect locally-declared variables to behave this way, and I'd still recommend using -g or -gH instead of -x. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: local but persistent integer? 2022-09-16 21:41 ` Bart Schaefer @ 2022-09-16 21:50 ` Ray Andrews 2022-09-17 1:51 ` Ray Andrews 1 sibling, 0 replies; 6+ messages in thread From: Ray Andrews @ 2022-09-16 21:50 UTC (permalink / raw) To: zsh-users On 2022-09-16 14:41, Bart Schaefer wrote: > On Fri, Sep 16, 2022 at 12:43 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> On 2022-09-16 10:44, Bart Schaefer wrote: >>> On Fri, Sep 16, 2022 at 8:19 AM Ray Andrews <rayandrews@eastlink.ca> wrote: >>>> integer -x start="$(( $(date +%s%N)/1000000 ))" >>>> >>>> ... I need 'start' to persist between function calls which it does >>> Given that construct, it should not. >> ... so it's visible externally as you say, but it's not going away either. > Hm, this is possibly a bug, but it's also possibly an expected > side-effect of "export" that I've forgotten about. My previous > statement is correct for string-scalars created with "typeset" and > "local" etc., but "integer" behaves differently. Counter intuitive for sure. I'd call it a gotcha. > I think this is > related to preserving the attributes of the variable (i.e., even if > unset, it remains an integer, so if you assign to it again it acts > like one) about which I believe I recall some discussion, but I don't > recall when it was implemented. > > In any case it's not reliable to expect locally-declared variables to > behave this way, and I'd still recommend using -g or -gH instead of > -x. Ok, I'll experiment with that, tho at the moment what I don't know isn't hurting me. Thanks Bart. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: local but persistent integer? 2022-09-16 21:41 ` Bart Schaefer 2022-09-16 21:50 ` Ray Andrews @ 2022-09-17 1:51 ` Ray Andrews 1 sibling, 0 replies; 6+ messages in thread From: Ray Andrews @ 2022-09-17 1:51 UTC (permalink / raw) To: zsh-users On 2022-09-16 14:41, Bart Schaefer wrote: > On Fri, Sep 16, 2022 at 12:43 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> On 2022-09-16 10:44, Bart Schaefer wrote: >> > In any case it's not reliable to expect locally-declared variables to > behave this way, and I'd still recommend using -g or -gH instead of > -x. Done. All runs as before and I'll take it on authority that it's better code. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-09-17 1:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-16 15:19 local but persistent integer? Ray Andrews 2022-09-16 17:44 ` Bart Schaefer 2022-09-16 19:43 ` Ray Andrews 2022-09-16 21:41 ` Bart Schaefer 2022-09-16 21:50 ` Ray Andrews 2022-09-17 1:51 ` 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).