Op 21-03-17 om 16:38 schreef Stephane Chazelas:
> IOW, the work around I was mentioning earlier (of using "local"
> before "unset" to make sure "unset" unsets) doesn't work in that
> case. You'd need to use the same work around as for mksh/yash
> (call unset in a loop until the variable is really u
> The effect of unset on a local was what I had in mind, but really the
> manual says very little about scope. All it says right now is:
>
> "Variables local to the function may be declared with the local builtin
> command. Ordinarily, variables and their values are shared between the
> function
On 3/21/17 3:19 AM, Dan Douglas wrote:
> Also not documented is how a variable declared with declare/typeset is
> distinct from an unset variable.
I don't know, I think this is pretty clear:
"A parameter is set if it has been assigned a value."
The previous paragraph discusses attributes. The
2017-03-20 16:32:10 -0400, Chet Ramey:
[...]
> > See also:
> >
> > $ bash -c 'f() { unset a; echo "$a";}; a=1; a=2 f'
> > 1
> >
> > already mentioned.
>
> A distinction without a difference; the behavior is explicitly the same.
[...]
One I haven't mentioned yet is:
$ bash -c 'f() { local a; un
On 03/18/2017 12:19 PM, Chet Ramey wrote:
> On 3/17/17 6:35 PM, Dan Douglas wrote:
>
>> The problem is the non-obvious nature of unset's interaction with scope,
>> (and the lack of documentation). Not much can be done about the former,
>> as it is with so many things.
>
> How would you suggest im
On 3/20/17 4:29 PM, Stephane Chazelas wrote:
>> I believe he means the behavior of `a=0; a=1 eval unset a', which Posix
>> implicitly requires affect the global scope and results in a being unset
>> when the statement completes.
> [...]
>
> See also:
>
> $ bash -c 'f() { unset a; echo "$a";}; a=
2017-03-20 14:47:17 -0400, Chet Ramey:
> On 3/20/17 2:30 PM, Eric Blake wrote:
> > On 03/17/2017 07:21 PM, Stephane Chazelas wrote:
> >
> >>> The problem is the non-obvious nature of unset's interaction with scope,
> >>
> >> the main problem to me is an unset command that doesn't unset.
> >>
> >>
On 3/20/17 2:30 PM, Eric Blake wrote:
> On 03/17/2017 07:21 PM, Stephane Chazelas wrote:
>
>>> The problem is the non-obvious nature of unset's interaction with scope,
>>
>> the main problem to me is an unset command that doesn't unset.
>>
>> As shown in my original post, there's also a POSIX conf
On 03/17/2017 07:21 PM, Stephane Chazelas wrote:
>> The problem is the non-obvious nature of unset's interaction with scope,
>
> the main problem to me is an unset command that doesn't unset.
>
> As shown in my original post, there's also a POSIX conformance
> issue.
As POSIX has not yet specif
It seems to me this matter is specific to the IFS variable (and possibly
few others like CDPATH). Unsetting IFS restores the default field splitting
behavior, but unsetting PATH does not restore the default command search
path. As Peter suggests, you can locally re-define any variables you
want and
2017-03-20 08:04:33 -0400, Greg Wooledge:
[...]
> > Credits to Dan Douglas
> > (https://www.mail-archive.com/miros-mksh@mirbsd.org/msg00707.html)
> > for finding the bug. He did find a use for it though (get the
> > value of a variable from the caller's scope).
>
> Isn't this exactly the same as t
On Fri, Mar 17, 2017 at 09:51:34PM +, Stephane Chazelas wrote:
> Then, the "unset", instead of unsetting IFS, actually pops a
> layer off the stack.
> Credits to Dan Douglas
> (https://www.mail-archive.com/miros-mksh@mirbsd.org/msg00707.html)
> for finding the bug. He did find a use for it tho
2017-03-20 12:30:09 +0900, 渡邊裕貴:
> It seems to me this matter is specific to the IFS variable (and possibly
> few others like CDPATH). Unsetting IFS restores the default field splitting
> behavior, but unsetting PATH does not restore the default command search
> path. As Peter suggests, you can loc
On 20/03/2560 04:51, Stephane Chazelas wrote:
> On comp.unix.shell ot http://unix.stackexchange.com, I've posted
> many articles describing how to do splitting in POSIX-like
> shells:
>
> ( # subshell for local scope
> unset -v IFS # restore default splitting behaviour
> set -o noglob # disab
On 3/19/17 6:22 PM, Stephane Chazelas wrote:
>> $ cat x2
>> function foo
>> {
>> (
>> unset -v IFS
>> recho "${IFS-unset}"
>> )
>> }
>>
>> IFS=':|'
>> foo
>> echo after IFS = "$IFS"
>> $ ../bash-4.4-patched/bash ./x2
>> argv[1] =
>> after IFS = :|
>
> Yes, that one is fine but it is n
2017-03-19 18:05:19 -0400, Chet Ramey:
> On 3/19/17 5:51 PM, Stephane Chazelas wrote:
>
> > On comp.unix.shell ot http://unix.stackexchange.com, I've posted
> > many articles describing how to do splitting in POSIX-like
> > shells:
> >
> > ( # subshell for local scope
> > unset -v IFS # restor
On 3/19/17 5:51 PM, Stephane Chazelas wrote:
> On comp.unix.shell ot http://unix.stackexchange.com, I've posted
> many articles describing how to do splitting in POSIX-like
> shells:
>
> ( # subshell for local scope
> unset -v IFS # restore default splitting behaviour
> set -o noglob # disab
2017-03-18 13:16:56 -0400, Chet Ramey:
> On 3/17/17 5:51 PM, Stephane Chazelas wrote:
>
> > Now, if that "split" functions is called from within a function
> > that declares $IFS local like:
> [...]
> > because after the "unset IFS", $IFS is not unset (which would
> > result in the default s
On 3/17/17 8:21 PM, Stephane Chazelas wrote:
> I don't expect the need to have to add "local var" in
>
> (
>unset -v var
>echo "${var-OK}"
> )
>
> would be obvious to many people beside you though.
Try the following:
function foo
{
(
unset -v IFS
recho "${IFS-unset}"
On 3/17/17 6:35 PM, Dan Douglas wrote:
> The problem is the non-obvious nature of unset's interaction with scope,
> (and the lack of documentation). Not much can be done about the former,
> as it is with so many things.
How would you suggest improving the documentation? I can see highlighting
the
On 3/17/17 5:51 PM, Stephane Chazelas wrote:
> Now, if that "split" functions is called from within a function
> that declares $IFS local like:
[...]
> because after the "unset IFS", $IFS is not unset (which would
> result in the default splitting behaviour) but set to ":" as it
> was befo
On 03/17/2017 09:16 PM, Dan Douglas wrote:
> Why
> would a subshell just make the call stack go away?
I guess slight correction, it's unset itself, because:
> In fact, mksh prints "global" even without the subshell, despite it
> using dynamic scope for either function definition syntax.
Another
On 03/17/2017 07:21 PM, Stephane Chazelas wrote:
> I don't expect the need to have to add "local var" in
>
> (
>unset -v var
>echo "${var-OK}"
> )
True. I would pretty much never use a subshell command group when I know
that locals are available though. And if I know locals are available
2017-03-17 17:35:36 -0500, Dan Douglas:
> The need to localize IFS is pretty obvious to me - of course that's
> given prior knowledge of how it works.
[...]
I don't expect the need to have to add "local var" in
(
unset -v var
echo "${var-OK}"
)
would be obvious to many people beside you th
The need to localize IFS is pretty obvious to me - of course that's
given prior knowledge of how it works.
The problem is the non-obvious nature of unset's interaction with scope,
(and the lack of documentation). Not much can be done about the former,
as it is with so many things.
It's probably easiest to find previous discussions here on this topic
by searching for 'upvar' (common name for a function that takes
advantage of this behavior).
Latest I think was this one [1] but a much earlier discussion is here [2].
[1] https://lists.gnu.org/archive/html//bug-bash/2015-01/
Hi,
consider this function:
split() (
unset -v IFS # default splitting
set -o noglob # disable glob
set -- $1 # split+(no)glob
[ "$#" -eq 0 ] || printf '<%s>\n' "$@"
)
Note the subshell above for the local scope for $IFS and for
the noglob option. That's a common idiom in POSIX shells
27 matches
Mail list logo
