* Read-only variables in emulation mode @ 2013-12-16 19:10 Øystein Walle 2013-12-16 19:40 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Øystein Walle @ 2013-12-16 19:10 UTC (permalink / raw) To: zsh-workers Hi, Consider the following: emulate sh -c ' some_name() { status=world echo "hello $status" } some_name ' Running it gives: some_name:1: read-only variable: status This is a problem if you source a "library" meant to be used by different versions of different shells: $ cat =git-example #!/bin/zsh emulate sh -c ' . git-sh-setup ' ... require_work_tree ... $ git example die_with_status:1: read-only variable: status A common idiom in (ba)sh scripting is to use _ as a throwaway in a while-read loop: while read -r col1 _ col2; do echo "col1 = $col1 and col2 = $col2" done < three-columns.txt This also fails with an equivalent message when used in sh emulation. Is it fixable? (Is the general opinion that it needs fixing?). I assume status and _ are meant to be writable in POSIX shells. I suppose an idea would be for various variables to be writable within emulate -c '...' and later in the functions defined therein. How this would affect the rest of the shell is hard to say for me. In the mean time, is there any way around it? Thanks Øsse ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2013-12-16 19:10 Read-only variables in emulation mode Øystein Walle @ 2013-12-16 19:40 ` Bart Schaefer 2013-12-18 6:36 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2013-12-16 19:40 UTC (permalink / raw) To: Oystein Walle, zsh-workers On Dec 16, 8:10pm, Oystein Walle wrote: } Subject: Read-only variables in emulation mode } } I assume status and _ are meant to be writable in POSIX shells. Hmm. According to the doc, "status" should be writable but "_" not. status <S> <Z> _ <S> (The <S> means "special", the <Z> means "but only in native zsh mode".) } A common idiom in (ba)sh scripting is to use _ as a throwaway in a } while-read loop: } } while read -r col1 _ col2; do } echo "col1 = $col1 and col2 = $col2" } done < three-columns.txt Well, that's one I'd never seen before. Certainly that's about the only place it's "safe" to use "_" because it's always immediately going to be clobbered. } In the mean time, is there any way around it? Only by using a function scope and declaring "local -h _ status" to hide the special variables. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2013-12-16 19:40 ` Bart Schaefer @ 2013-12-18 6:36 ` Bart Schaefer 2013-12-18 19:28 ` Peter Stephenson 0 siblings, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2013-12-18 6:36 UTC (permalink / raw) To: zsh-workers On Dec 16, 11:40am, Bart Schaefer wrote: } Subject: Re: Read-only variables in emulation mode } } On Dec 16, 8:10pm, Oystein Walle wrote: } } Subject: Read-only variables in emulation mode } } } } I assume status and _ are meant to be writable in POSIX shells. } } Hmm. According to the doc, "status" should be writable but "_" not. I looked a bit more closely at this and found that when zsh is *started* in POSIX shell mode (e.g., the executable name is sh or ksh), then the "status" variable is non-special, as expected. It's a known limitation that invoking "emulate ..." after the shell is already running does completely re-instantiate POSIX mode. This is not likely to change. However, I don't think there's any particular reason we couldn't remove the readonly property from $_ if that would improve compatibility. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2013-12-18 6:36 ` Bart Schaefer @ 2013-12-18 19:28 ` Peter Stephenson 2013-12-19 7:57 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Peter Stephenson @ 2013-12-18 19:28 UTC (permalink / raw) To: zsh-workers On Tue, 17 Dec 2013 22:36:51 -0800 Bart Schaefer <schaefer@brasslantern.com> wrote: > It's a known limitation that invoking "emulate ..." after the shell is > already running does completely re-instantiate POSIX mode. This is not > likely to change. I don't expect I'll get round to it myself, but in the case of variables, I don't think this should be that difficult. The variables need saving and hiding on entry to emulation and restoring afterwards. Most of the significant chunks of code for that are already in place. pws ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2013-12-18 19:28 ` Peter Stephenson @ 2013-12-19 7:57 ` Bart Schaefer 2015-06-16 0:10 ` Mikael Magnusson 0 siblings, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2013-12-19 7:57 UTC (permalink / raw) To: zsh-workers On Dec 18, 7:28pm, Peter Stephenson wrote: } Subject: Re: Read-only variables in emulation mode } } On Tue, 17 Dec 2013 22:36:51 -0800 } Bart Schaefer <schaefer@brasslantern.com> wrote: } > It's a known limitation that invoking "emulate ..." after the shell is } > already running does [not] completely re-instantiate POSIX mode. } } I don't expect I'll get round to it myself, but in the case of } variables, I don't think this should be that difficult. The part about "_" is easy, though: diff --git a/Src/params.c b/Src/params.c index 26ad6b2..cadf268 100644 --- a/Src/params.c +++ b/Src/params.c @@ -283,7 +283,7 @@ IPDEF2("TERM", term_gsu, 0), IPDEF2("TERMINFO", terminfo_gsu, PM_UNSET), IPDEF2("WORDCHARS", wordchars_gsu, 0), IPDEF2("IFS", ifs_gsu, PM_DONTIMPORT), -IPDEF2("_", underscore_gsu, PM_READONLY), +IPDEF2("_", underscore_gsu, PM_DONTIMPORT), IPDEF2("KEYBOARD_HACK", keyboard_hack_gsu, PM_DONTIMPORT), #ifdef USE_LOCALE Feel free to commit that for me if you want it to go into 5.0.4, I'm going to be asleep for the next several hours ... ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2013-12-19 7:57 ` Bart Schaefer @ 2015-06-16 0:10 ` Mikael Magnusson 2015-06-16 3:24 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Mikael Magnusson @ 2015-06-16 0:10 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh workers On Thu, Dec 19, 2013 at 8:57 AM, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Dec 18, 7:28pm, Peter Stephenson wrote: > } Subject: Re: Read-only variables in emulation mode > } > } On Tue, 17 Dec 2013 22:36:51 -0800 > } Bart Schaefer <schaefer@brasslantern.com> wrote: > } > It's a known limitation that invoking "emulate ..." after the shell is > } > already running does [not] completely re-instantiate POSIX mode. > } > } I don't expect I'll get round to it myself, but in the case of > } variables, I don't think this should be that difficult. > > The part about "_" is easy, though: > > diff --git a/Src/params.c b/Src/params.c > index 26ad6b2..cadf268 100644 > --- a/Src/params.c > +++ b/Src/params.c > @@ -283,7 +283,7 @@ IPDEF2("TERM", term_gsu, 0), > IPDEF2("TERMINFO", terminfo_gsu, PM_UNSET), > IPDEF2("WORDCHARS", wordchars_gsu, 0), > IPDEF2("IFS", ifs_gsu, PM_DONTIMPORT), > -IPDEF2("_", underscore_gsu, PM_READONLY), > +IPDEF2("_", underscore_gsu, PM_DONTIMPORT), > IPDEF2("KEYBOARD_HACK", keyboard_hack_gsu, PM_DONTIMPORT), > > #ifdef USE_LOCALE > > > Feel free to commit that for me if you want it to go into 5.0.4, I'm > going to be asleep for the next several hours ... % echo hi; _=foo; echo $_ hi hi % for _ in a b c; do echo $_ hi; done hi hi hi hi hi I'm not sure if this is better than printing a warning that $_ is readonly. :) -- Mikael Magnusson ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2015-06-16 0:10 ` Mikael Magnusson @ 2015-06-16 3:24 ` Bart Schaefer 2015-06-16 6:24 ` Mikael Magnusson 2015-06-16 19:05 ` Bart Schaefer 0 siblings, 2 replies; 11+ messages in thread From: Bart Schaefer @ 2015-06-16 3:24 UTC (permalink / raw) To: zsh workers On Jun 16, 2:10am, Mikael Magnusson wrote: } } % echo hi; _=foo; echo $_ } hi } hi That's actually a bug -- the assignment _=foo should erase $_ , I think. } % for _ in a b c; do echo $_ hi; done } hi } hi hi } hi hi } } I'm not sure if this is better than printing a warning that $_ is } readonly. :) If you go back to the original message in the thread, the whole point was to use $_ as a dummy variable that didn't need to be declared and whose value was instantly discarded. For that purpose, the warning is extraneous. Admittedly that's a pretty constrained use case. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2015-06-16 3:24 ` Bart Schaefer @ 2015-06-16 6:24 ` Mikael Magnusson 2015-06-16 15:54 ` Bart Schaefer 2015-06-16 19:05 ` Bart Schaefer 1 sibling, 1 reply; 11+ messages in thread From: Mikael Magnusson @ 2015-06-16 6:24 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh workers On Tue, Jun 16, 2015 at 5:24 AM, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Jun 16, 2:10am, Mikael Magnusson wrote: > } > } % echo hi; _=foo; echo $_ > } hi > } hi > > That's actually a bug -- the assignment _=foo should erase $_ , I think. > > } % for _ in a b c; do echo $_ hi; done > } hi > } hi hi > } hi hi > } > } I'm not sure if this is better than printing a warning that $_ is > } readonly. :) > > If you go back to the original message in the thread, the whole point > was to use $_ as a dummy variable that didn't need to be declared and > whose value was instantly discarded. For that purpose, the warning is > extraneous. > > Admittedly that's a pretty constrained use case. It's currently hooked up to nullstrsetfn, and was when it was readonly too, so I guess this never worked as intended. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2015-06-16 6:24 ` Mikael Magnusson @ 2015-06-16 15:54 ` Bart Schaefer 2015-06-16 21:06 ` Mikael Magnusson 0 siblings, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2015-06-16 15:54 UTC (permalink / raw) To: zsh workers On Jun 16, 8:24am, Mikael Magnusson wrote: } } > On Jun 16, 2:10am, Mikael Magnusson wrote: } > } } > } % echo hi; _=foo; echo $_ } > } hi } > } hi } > } > That's actually a bug -- the assignment _=foo should erase $_ , I think. } > } > } % for _ in a b c; do echo $_ hi; done } > } hi } > } hi hi } > } hi hi } > } > If you go back to the original message in the thread, the whole point } > was to use $_ as a dummy variable that didn't need to be declared and } > whose value was instantly discarded. For that purpose, the warning is } > extraneous. } } It's currently hooked up to nullstrsetfn, and was when it was readonly } too, so I guess this never worked as intended. I'm not sure what "never worked as intended" is aimed at. "That's actually a bug" -- $_ should be erased because there is no command for a last argument to be taken from, not because it's been assigned foo. "use $_ as a dummy variable" -- that didn't work as intended before, but it does now. So what never worked and what was intended? As with $0 in the other thread, "local -h _" works. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2015-06-16 15:54 ` Bart Schaefer @ 2015-06-16 21:06 ` Mikael Magnusson 0 siblings, 0 replies; 11+ messages in thread From: Mikael Magnusson @ 2015-06-16 21:06 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh workers On Tue, Jun 16, 2015 at 5:54 PM, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Jun 16, 8:24am, Mikael Magnusson wrote: > } > } > On Jun 16, 2:10am, Mikael Magnusson wrote: > } > } > } > } % echo hi; _=foo; echo $_ > } > } hi > } > } hi > } > > } > That's actually a bug -- the assignment _=foo should erase $_ , I think. > } > > } > } % for _ in a b c; do echo $_ hi; done > } > } hi > } > } hi hi > } > } hi hi > } > > } > If you go back to the original message in the thread, the whole point > } > was to use $_ as a dummy variable that didn't need to be declared and > } > whose value was instantly discarded. For that purpose, the warning is > } > extraneous. > } > } It's currently hooked up to nullstrsetfn, and was when it was readonly > } too, so I guess this never worked as intended. > > I'm not sure what "never worked as intended" is aimed at. > > "That's actually a bug" -- $_ should be erased because there is no command > for a last argument to be taken from, not because it's been assigned foo. > > "use $_ as a dummy variable" -- that didn't work as intended before, but > it does now. > > So what never worked and what was intended? > > As with $0 in the other thread, "local -h _" works. Oh, the intention was never to actually use the assigned value of $_? In that case I completely misunderstood things... Oops, I just went back to the original message and noticed "throwaway" now. I came here from IRC where we were talking about using variables without having to declare them local, so my context was a bit wrong. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Read-only variables in emulation mode 2015-06-16 3:24 ` Bart Schaefer 2015-06-16 6:24 ` Mikael Magnusson @ 2015-06-16 19:05 ` Bart Schaefer 1 sibling, 0 replies; 11+ messages in thread From: Bart Schaefer @ 2015-06-16 19:05 UTC (permalink / raw) To: zsh workers On Jun 15, 8:24pm, Bart Schaefer wrote: } } On Jun 16, 2:10am, Mikael Magnusson wrote: } } } } % echo hi; _=foo; echo $_ } } hi } } hi } } That's actually a bug -- the assignment _=foo should erase $_ , I think. Anybody see a problem with this? diff --git a/Src/exec.c b/Src/exec.c index daed3b1..35a101b 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -1115,6 +1115,7 @@ execsimple(Estate state) if (code == WC_ASSIGN) { cmdoutval = 0; addvars(state, state->pc - 1, 0); + setunderscore(""); if (isset(XTRACE)) { fputc('\n', xtrerr); fflush(xtrerr); ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-06-16 21:07 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-12-16 19:10 Read-only variables in emulation mode Øystein Walle 2013-12-16 19:40 ` Bart Schaefer 2013-12-18 6:36 ` Bart Schaefer 2013-12-18 19:28 ` Peter Stephenson 2013-12-19 7:57 ` Bart Schaefer 2015-06-16 0:10 ` Mikael Magnusson 2015-06-16 3:24 ` Bart Schaefer 2015-06-16 6:24 ` Mikael Magnusson 2015-06-16 15:54 ` Bart Schaefer 2015-06-16 21:06 ` Mikael Magnusson 2015-06-16 19:05 ` Bart Schaefer
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).