> On 2018 Feb 26 , at 4:31 a, Robert Elz <k...@munnari.oz.au> wrote: > > Date: Mon, 12 Feb 2018 09:26:37 -0500 > From: Chet Ramey <chet.ra...@case.edu> > Message-ID: <790ade74-690f-541c-9ab4-635991744...@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