1

Regarding Bourne shell and derivates, I understand IFS to be a behavior program for field splitting (commanding how to split fields into "words") which is needed for a broader process named "parsing".

I have read that If IFS (as an environment variable) is not set (as with unset IFS), the shell shall behave as if the value of IFS is <space>, <tab> and <newline>.

Putting the possible atrocious consequences aside for a moment, intuitively I would think that unsetting an environment variable would delete it without warnings similar to how rm -rf /* can just destroy a system without warnings and similar to what happens with unset xyz (as unsetting an artificially made non environment variable which is then deleted).

So, I would say that unset IFS isn't really unsetting it but resetting it (somewhere else) into some default fallback behavior.

Is unsetting environment variables always cause some fallback behavior?

variableexpander
  • 47
  • 4
  • 1
    I can't help but wonder where this question is coming from. Note that the [POSIX text](https://unix.stackexchange.com/a/639727/170373) or e.g. Bash's manual don't say that `IFS` would be set to ``if unset, just the relevant functions (i.e. field/word splitting and `$*`) act like it would have that value. Also, `IFS` is a somewhat special case in being integral to how the shell works. Is there some reason in particular to assume that unset variable in general wouldn't be basically deleted? – ilkkachu Mar 17 '21 at 15:44
  • `just the relevant functions (i.e. field/word splitting and $*) act like it would have that value` isn't that the main functionality of IFS? – variableexpander Mar 17 '21 at 15:51
  • `Is there some reason in particular to assume that unset variable in general wouldn't be basically deleted?` Because I understood, most probably wrongly, that `unset IFS` would reset its value to `` and I wanted to understand why. – variableexpander Mar 17 '21 at 15:52
  • @ilkkachu this question comes from me confusing `If IFS is not set, the shell shall behave as if the value of IFS is , and ` (especially the `will behave as`) with `will reset as` or `will fallback to`. Still this `will behave as` resembles some fallback behavior... Wouldn't you say?... – variableexpander Mar 17 '21 at 16:11
  • Anyway, @ilkkachu I have edited to improve the question based on your helpful comment. – variableexpander Mar 17 '21 at 16:43

1 Answers1

3

This is not bash specific, but applies to all shells that implement POSIX behavior.

Unsetting IFS with unset IFS will unset the variable. It will not magically get another value.

The POSIX standard explicitly says

If IFS is not set, it shall behave as normal for an unset variable [...]

It goes on to say that when the shell wants to do field splitting (splitting unquoted values, splitting read input, but also when delimiting the positional parameters in the "$*" string), and when IFS is unset, it should behave as if the IFS variable had the value of a space, tab and newline character.

This is not different than saying that a utility (in this case, the shell) will use a variable if it's available, and otherwise have some well defined default behavior.

Also note that IFS is not, and should not be, an environment variable. I.e., it never needs to be exported. It's only ever used by the current shell and its built in read utility. A shell will set IFS to a space, tab and newline character when it starts.

See also the section on special shell variables in the POSIX standard.

Kusalananda
  • 320,670
  • 36
  • 633
  • 936
  • I always enjoy when I read your answers. – variableexpander Mar 17 '21 at 19:33
  • About *unset or null*; I think that this "null" is different than the null of `IFS=`, `IFS=''` and `IFS=""` were no field splitting will be performed at all and with `echo "$*"` all fields will be concatenated together with no spaces. – variableexpander Mar 17 '21 at 19:33
  • @variableexpander Sorry, the "or null" bit was something that I had no support for. It has been removed. – Kusalananda Mar 17 '21 at 19:43