zsh-workers
 help / color / mirror / code / Atom feed
* 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  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

* 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

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).