Date:        Mon, 26 Feb 2018 09:57:10 -0500
    From:        Clint Hepner <clint.hep...@gmail.com>
    Message-ID:  <f9db73d6-f1ef-4f50-8302-3d42d72c1...@gmail.com>

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

The effect of unset IFS is POSIX, and has been around forever, I think I'll
rely upon that more than any of the others.   It has nothing to do with how
many characters need to be typed.

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

I know, but support for local has been around for a long time, and is in just 
about every shell that exists (and only not in posix, as I understand it, 
because of disagreements about scoping rules.)   While $'...' support is
becoming more common -- for a long time, it was much less likely to be found.

In any case, anything related to IFS and $' ... ' is a side issue, unrelated 
to the real point of the message (the $'..' was just a way to set IFS, rather 
than unset it, which should not be needed at all, and IFS was just an example, 
unset of a local should work sensibly for all variables.)

  | If portability is your goal, making a nonstandard change to one shell isn't 
going to help.

No, it wasn't - rational design choices was the goal.

  | Suppose bash did change the behavior of unset (even optionally) or added an 
"unlocal"
  | command,

The unlocal is another side issue, I don't think anything like that is needed 
at all.

  | and you made use of this. Now your script is limited to bash 4.5 or newer,

I don't write scripts for bash (I do use it interactively) and the shell I do 
use for scripts does all this "properly" - I wasn't making a feature request,
just cirticising a design choice.

  | and *maybe* any other shell that could be convinced to implement something 
similar.

I believe that most shells that implement local (which is most shells) 
implement unset of a local as meaning the local var becomes unset,
not that it vanishes and the global reappears.

  | $'...' already enjoys wider level of support.

Perhaps, but irrelevant - that was only material because of being a way to
avoid needing to unset IFS - which is no more than an example in any case.

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

I know, but it wasn't so much people, as things like mailers which have been 
known to screw with trailing whitespace on lines (and of course it is 
almost impossible to represent cleanly in printed form) - but none of this
really matters.

  | If necessary, you can define a global (at the expense of a single 
subprocess)
  |
  |     myIFS=$(printf ' \t\n')

Again, this is irrelevant, but if it were not, the subprocess would not 
matter, but the use of a global would - it assumes knowledge of the
namespace of the script in which the function is to be used - if that
sort of knowledge could be assumed we would never need local in
the first place (and were IFS to be important, we would also know what
value it would have, and could probably not need to modify it at all.)

kre


Reply via email to