bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unset array doesn't work


From: Clint Hepner
Subject: Re: Unset array doesn't work
Date: Mon, 26 Feb 2018 09:57:10 -0500

> On 2018 Feb 26 , at 4:31 a, Robert Elz <kre@munnari.OZ.AU> wrote:
> 
>    Date:        Mon, 12 Feb 2018 09:26:37 -0500
>    From:        Chet Ramey <chet.ramey@case.edu>
>    Message-ID:  <790ade74-690f-541c-9ab4-6359917442d0@case.edu>
> 
>  | This is bash's dynamic scoping. The visibility of a local variable is
>  | restricted to a function and its children, and `unset' removes the
>  | currently-visible instance. Removing such an instance can `unconver' an
>  | instance in a previous scope.
> 
> Frankly this is brain dead, unset should not be unlocal (or something equiv)
> 
> eg: if I have a func
> 
>       myfunc() {
>               local IFS
>               unset IFS
>               # do some code
>       }
> 
> the very last thing that I want is for the global IFS to apply.
> 
> The intent is to use the default IFS value, which is what an unset IFS
> produces, without affecting the current global IFS setting.

As you say, the intent is to use a particular value of the variable. The fact 
that unsetting
IFS causes it to use a default value other than an empty string seems more like 
a concession
to historical usage than a feature that should be explicitly used. If you need 
a particular
value, assign it instead of using a nonobvious alternative that is only shorter 
by three of characters:

    IFS=$' \t\n'
    unset IFS

> In this example, I could do IFS=$' \t\n' if I was willing to assume that 
> $'...'
> support exists (the shell executing the script is not necessarily going to
> be bash)

You are already assuming $'...'-support if you are using local; both are bash 
extensions
to the POSIX standard.

If portability is your goal, making a nonstandard change to one shell isn't 
going to help. Suppose
bash did change the behavior of unset (even optionally) or added an "unlocal" 
command, and you
made use of this. Now your script is limited to bash 4.5 or newer, and *maybe* 
any other shell that
could be convinced to implement something similar. $'...' already enjoys wider 
level of support.

> or I could do
> 
>               IFS='   
> '
> 
> and just hope that survives as written (it would straight from the editor,
> but who knows when someone else decides that trailing whitespace on
> lines should all be deleted).   Variants to avoid that get even uglier.

People who remove whitespace from inside quotes do so at their own risk. Not all
trailing whitespace is extraneous.

If necessary, you can define a global (at the expense of a single subprocess)

    myIFS=$(printf ' \t\n')

to get a value in a completely POSIX-compatible way you can use to assign to a 
localized
copy of IFS. (But I want to reiterate that you have already thrown POSIX 
compatibility out
the window by using local in the first place, so you might as well use $' 
\t\n'.)

-- 
Clint


reply via email to

[Prev in Thread] Current Thread [Next in Thread]