Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin11.4.2 Compiler: /usr/bin/clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='darwin11.4.2' -DCONF_MACHTYPE='x86_64-apple-darwin11.4.2' -DCONF_VENDOR='apple' -DLOCALEDIR='/opt/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I/opt/local/include -pipe -Os -DSSH_SOURCE_BASHRC -arch x86_64 uname output: Darwin breedzicht.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 Machine Type: x86_64-apple-darwin11.4.2
Bash Version: 4.3 Patch Level: 42 Release Status: release Description: The substitution ${1+"$@"} should resolve to "$@" if there is at least one parameter -- i.e. one word per parameter. This works fine if IFS contains any character or is unset. If IFS is empty, it instead resolves to the equivalent of "$*", i.e. a single word concatenating all the parameters without a separator. IFS should not influence the behaviour of "$@" under any circumstances. (d)ash variants, AT&T ksh, mksh, zsh, yash all do this correctly. bash 2.05b.13 also does this correctly (!). The bug is present in bash 3.2.57 and bash 4.3.42. (In bash, ${1+"$@"} is redundant, but in some old versions of ksh and other shells, if 'set -u' is active, "$@" throws an error if there are no parameters, so ${1+"$@"} is used as a workaround. As a result, this is often found in cross-platform scripts. These break on bash 3 & 4 if fieldsplitting is disabled by emptying IFS.) Repeat-By: $ IFS='' # bug only occurs on empty IFS $ set -- this is a test $ printf '|%s|\n' ${1+"$@"} # generates wrong output |thisisatest| $ printf '|%s|\n' "$@" # generates correct output |this| |is| |a| |test|