Sometimes when writing script it can be necessary to set IFS(the internal field separator) to something other than the default, e.g. to change the way $* will be expanded.

While this is totally plausible I can't think of any reason to set IFS in interactive shells to anything but the default (which is space, tab and newline if I remember correctly). Still I was often told that on an interactive shell I can't expect IFS to be set to it's default value.

Is this really true? Can anyone give practical examples?

  • 2
    Your question would be better if you explained the acronym IFS.
    – N.N.
    Commented Feb 27, 2013 at 15:25
  • it is the internal field separator in this context. i agree he should have clarified.
    – amphibient
    Commented Feb 27, 2013 at 16:20
  • @foampile Please include it in your question by editing it rather than putting it in a comment. Will be easier for others to spot then.
    – N.N.
    Commented Feb 27, 2013 at 16:48
  • @N.N. -- the question was not mine. do check
    – amphibient
    Commented Feb 27, 2013 at 16:49
  • but i did edit the OP, it is pending approval
    – amphibient
    Commented Feb 27, 2013 at 16:50

2 Answers 2


In an interactive shell, $IFS will be the default unless you changed it or something in shell startup scripts (like ~/.bashrc for bash) or any other scripts sourced or shell functions executed since the shell was started change it (they generally wouldn't or would change it back to the default if they are properly written though).

If those functions defined in rc files or other sourced files are properly written and they need to use word splitting, they would not assume anything on the current value of IFS, so it should be fine for you do set it to a different value.

However, once you change it, you have to remember that you did as that might affect the way command lines you run later are interpreted.

For instance, if you do:

IFS=:; ls -- $PATH

To list the directories in $PATH, you might wonder why later on things like:

rm -f -- $(cat ~/my.file.list)

do not work any more. So you might as well write it:

(IFS=:; ls -- $PATH)


IFS=:; ls -- $PATH; unset IFS

(BTW, unset IFS restores the word splitting to its default behaviour, but not $IFS and it breaks the (not properly written) functions that do things like oldIFS=$IFS; IFS=xxx; ...; IFS=$oldIFS to restore $IFS).

  • You can also set it for a single command IFS=: ls -- $PATH, without the subshell.
    – jordanm
    Commented Feb 27, 2013 at 16:28
  • 3
    @jordanm, No. that inserts IFS=: into the environment passed to ls (which has no use for it), but doesn't affect how that $PATH is split in this command line. You could do IFS=: command eval 'ls -- $PATH', but that's a bit cumbersome. Commented Feb 27, 2013 at 16:35
  • Why bother with command eval when just eval seems like it would do in that case?
    – mtraceur
    Commented Jul 30, 2022 at 15:33
  • Also, "[shell functions] would change [IFS] back to the default if they are properly written" can get really hard to achieve for non-trivial portable logic: it's easy if the whole program fits in one human's head, but if you've got function foo calling function bar, well then foo might want to set IFS for something while calling bar, but then someone comes along and refactors bar to call function qux which was written elsewhere by someone assuming IFS would always be the default, and suddenly things break due to not-local-to-bar interactions between foo and qux. (1/2)
    – mtraceur
    Commented Jul 30, 2022 at 15:38
  • ..and at the same time, unless you can rely on local variables (which are available on every modern shell I've tried on Linux but certainly weren't in Bourne shell) or are willing and able to write your function bodies as subshells, then function foo can't just use a name like old_IFS to store IFS while calling bar with a modified IFS - because what if bar is already or in the future written to use the same trick, setting old_IFS internally and thus clobbering the old value. This can be worked-around but you have to consciously go out of the way to handle it. (2/2)
    – mtraceur
    Commented Jul 30, 2022 at 15:45

Of course you can and should expect that IFS is set to default, as without it, all sorts of commands will simply stop working altogether.

You change IFS in a shell (temporarily) for the same reasons you do it in a bash script, when you happen to need it (which rarely ever happens). If you're going to use a specific command only once there is no reason to write it into a shell script. Other than that there is no difference between a shell script, and using the shell directly.

  • 2
    To remove confusion, IFS is not exported to the environment, and even if it is shells, ignore it upon starting, so setting IFS is the interactive shells will not affect any command started by that shell, unless those commands are built in the shell like read or . (aka source) or the functions you define. Commented Feb 27, 2013 at 16:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .