关于Bash中declare重置IFS及数组创建行为差异的技术疑问

这个问题的核心在于Bash的命令解析顺序和**declare内置命令的特殊环境规则**，咱们一步步拆解来搞懂：

首先看能正常工作的第一种写法：

declare -a themes
IFS=$'\n'
themes=($(plutil -extract 'Window Settings' xml1 -o - - <<< "$terminal_settings" | xmllint --xpath '/plist/dict/key/node()' -))

它的执行逻辑是：

1. 先声明themes为数组类型，这一步只是给变量打标签，不影响后续的赋值逻辑
2. 修改当前shell的全局IFS为换行符，此时整个shell环境的分词规则变成只认换行
3. 执行命令替换$(...)拿到换行分隔的输出，因为当前IFS是换行，数组赋值themes=(...)会把每个换行分隔的内容单独作为一个数组元素，完美符合预期

再看失效的第二种写法：

IFS=$'\n' declare -a themes=($(plutil -extract 'Window Settings' xml1 -o - - <<< "$terminal_settings" | xmllint --xpath '/plist/dict/key/node()' -))

这里的坑点是：当你把变量赋值（比如IFS=$'\n'）放在内置命令前面时，这个变量只对该内置命令的执行环境生效，完全不影响命令替换和数组赋值的分词过程。

具体来说，Bash在解析这条命令时：

• 会先把IFS=$'\n'作为declare命令的临时环境变量，但declare本身只是负责定义themes为数组，它不会处理后面=($(...))里的分词展开
• 而数组赋值里的命令替换$(...)和后续的分词，是在当前shell的原有环境中执行的——也就是IFS还是默认的空格、制表符、换行的组合，所以输出里的空格会被当成分隔符，把内容拆成多个数组元素，这就是你看到的现象

如果想让第二种写法生效，得让IFS的修改覆盖到数组赋值的整个过程，比如用&&把命令连起来，让IFS的修改在当前shell生效后再执行declare赋值：

IFS=$'\n' && declare -a themes=($(plutil -extract 'Window Settings' xml1 -o - - <<< "$terminal_settings" | xmllint --xpath '/plist/dict/key/node()' -))

不过更稳妥的方式是用Bash 4+提供的readarray（或mapfile）命令，完全绕开IFS的问题，直接按行读取内容到数组：

readarray -t themes < <(plutil -extract 'Window Settings' xml1 -o - - <<< "$terminal_settings" | xmllint --xpath '/plist/dict/key/node()' -)

-t参数会自动去掉每行末尾的换行符，用法更简洁也更不容易出错。

最后总结几个关键知识点：

• 内置命令前的变量赋值，仅对该命令的执行环境有效，不影响shell的全局分词规则
• 数组赋值的分词展开，依赖于当前shell的IFS设置，和declare命令的临时环境无关
• 临时修改IFS时，建议用完后恢复原值（比如OLD_IFS=$IFS; IFS=$'\n'; ...; IFS=$OLD_IFS），避免影响后续命令的执行

内容来源于stack exchange