Read-only variables in emulation mode

Read-only variables in emulation mode

[Øystein Walle]

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

Re: Read-only variables in emulation mode

[Bart Schaefer]

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.

Re: Read-only variables in emulation mode

[Bart Schaefer]

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.

Re: Read-only variables in emulation mode

[Peter Stephenson]

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

Re: Read-only variables in emulation mode

[Bart Schaefer]

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

Re: Read-only variables in emulation mode

[Mikael Magnusson]

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

Re: Read-only variables in emulation mode

[Bart Schaefer]

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.

Re: Read-only variables in emulation mode

[Mikael Magnusson]

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

Re: Read-only variables in emulation mode

[Bart Schaefer]

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.

Re: Read-only variables in emulation mode

[Bart Schaefer]

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

Re: Read-only variables in emulation mode

[Mikael Magnusson]

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