Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I know that a custom IFS value can be set for the scope of a single command/built-in. Is there a way to set a custom IFS value for a single statement?? Apparently not, since based on the below the global IFS value is affected when this is attempted

#check environment IFS value, it is space-tab-newline
printf "%s" "$IFS" | od -bc
0000000 040 011 012
             \t  \n
#invoke built-in with custom IFS
IFS=$'\n' read -r -d '' -a arr <<< "$str"
#environment IFS value remains unchanged as seen below
printf "%s" "$IFS" | od -bc
0000000 040 011 012
             \t  \n

#now attempt to set IFS for a single statement
IFS=$'\n' a=($str)
#BUT environment IFS value is overwritten as seen below
printf "%s" "$IFS" | od -bc
0000000 012
share|improve this question

3 Answers 3

up vote 8 down vote accepted

In some shells (including bash):

IFS=: command eval 'p=($PATH)'

(with bash, you can omit the command if not in sh/POSIX emulation). But beware that when using unquoted variables, you also generally need to set -f, and there's no local scope for that in most shells.

With zsh, you can do:

(){ local IFS=:; p=($=PATH); }

$=PATH is to force word splitting which is not done by default in zsh (globbing upon variable expansion is not done either so you don't need set -f unless in sh emulation).

(){...} (or function {...}) are called anonymous functions and are typically used to set a local scope. with other shells that support local scope in functions, you could do something similar with:

e() { eval "$@"; }
e 'local IFS=:; p=($PATH)'

To implement a local scope for variables and options in POSIX shells, you can also use the functions provided at https://github.com/stephane-chazelas/misc-scripts/blob/master/locvar.sh. Then you can use it as:

. /path/to/locvar.sh
call eval 'locvar IFS; locopt -f; IFS=,; set -- $var; a=$1 b=$2 c=$3'

(by the way, it's invalid to split $PATH that way above except in zsh as in other shells, IFS is field delimiter, not field separator).

IFS=$'\n' a=($str)

Is just two assignments, one after the other just like a=1 b=2.

A note of explanation on var=value cmd:


var=value cmd arg

The shell executes /path/to/cmd in a new process and passes cmd and arg in argv[] and var=value in envp[]. That's not really a variable assignment, but more passing environment variables to the executed command. In the Bourne or Korn shell, with set -k, you can even write it cmd var=value arg.

Now, that doesn't apply to builtins or functions which are not executed. In the Bourne shell, in var=value some-builtin, var ends up being set afterwards, just like with var=value alone. That means for instance that the behaviour of var=value echo foo (which is not useful) varies depending on whether echo is builtin or not.

POSIX and/or ksh changed that in that that Bourne behaviour only happens for a category of builtins called special builtins. eval is a special builtin, read is not. For non special builtin, var=value builtin sets var only for the execution of the builtin which makes it behave similarly to when an external command is being run.

The command command can be used to remove the special attribute of those special builtins. What POSIX overlooked though is that for the eval and . builtins, that would mean that shells would have to implement a variable stack (even though it doesn't specify the local or typeset scope limiting commands), because you could do:

a=0; a=1 command eval 'a=2 command eval echo \$a; echo $a'; echo $a

Or even:

a=1 command eval myfunction

with myfunction being a function using or setting $a and potentially calling command eval.

That was really an overlook because ksh (which the spec is mostly based on) didn't implement it (and AT&T ksh and zsh still don't), but nowadays, except those two, most shells implement it. Behaviour varies among shells though in things like:

a=0; a=1 command eval a=2; echo "$a"

though. Using local on shells that support it is a more reliable way to implement local scope.

share|improve this answer
Weirdly, IFS=: command eval … sets IFS only for the duration of the eval, as mandated by POSIX, in dash, pdksh and bash, but not in ksh 93u. It's unusual to see ksh being the odd-non-compliant-one-out. –  Gilles Sep 24 '13 at 21:29

Standard save-and-restore taken from "The Unix Programming Environment" by Kernighan and Pike:

share|improve this answer
thank you and +1. Yes I am aware of this option, but I would like to know if there is a "cleaner" option if you know what i mean –  1_CR Sep 24 '13 at 16:46
You could jam it onto one line with semi-colons, but I don't think that's cleaner. It might be nice if everything you wanted to express had special syntactic support, but then we'd probably have to learn carpentry or sumptin instead of coding ;) –  msw Sep 24 '13 at 16:49
Correct me if I'm wrong, but shouldn't you be able to modify the "invoke builtin with custom IFS" example from your previous statement? What is it about IFS=$'\n' read -r -d '' -a arr <<< "$str" that doesn't do what you want? –  The Spooniest Sep 24 '13 at 16:54
That fails to restore $IFS correctly if it was previously unset. –  Stéphane Chazelas Sep 24 '13 at 17:17

Put your script into a function and invoke that function passing the commandline arguments to it. As IFS is defined local, changes to it don't affect the global IFS.

main() {
  local IFS='/'

  # the rest goes here

main "$@"
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.