Solución:
Los primeros shells tenían un solo tipo de datos: cadenas. Pero es común manipular listas de cadenas, generalmente cuando se pasan varios nombres de archivos como argumentos a un programa. Otro caso de uso común para dividir es cuando un comando genera una lista de resultados: la salida del comando es una cadena, pero los datos deseados son una lista de cadenas. Para almacenar una lista de nombres de archivos en una variable, debe poner espacios entre ellos. Entonces un script de shell como este
files="foo bar qux"
myprogram $files
llamado myprogram con tres argumentos, ya que el shell divide la cadena $files en palabras. En ese momento, los espacios en los nombres de los archivos estaban prohibidos o se consideraban como No terminado.
El shell Korn introdujo matrices: podría almacenar una lista de cadenas en una variable. El shell Korn siguió siendo compatible con el shell Bourne establecido en ese momento, por lo que las expansiones de variables desnudas siguieron experimentando división de palabras, y el uso de matrices requirió cierta sobrecarga sintáctica. Escribirías el fragmento de arriba
files=(foo bar qux)
myprogram "${files[@]}"
Zsh tenía matrices desde el principio, y su autor optó por un diseño de lenguaje más sano a expensas de la compatibilidad con versiones anteriores. En zsh (bajo las reglas de expansión predeterminadas) $var no realiza división de palabras; si desea almacenar una lista de palabras en una variable, debe usar una matriz; y si realmente quieres dividir las palabras, puedes escribir $=var.
files=(foo bar qux)
myprogram $files
En estos días, los espacios en los nombres de los archivos son algo con lo que debe lidiar, tanto porque muchos usuarios esperan que funcionen como porque muchos scripts se ejecutan en contextos sensibles a la seguridad donde un atacante puede tener el control de los nombres de los archivos. De modo que la división automática de palabras suele ser una molestia; de ahí mi consejo general de usar siempre comillas dobles, es decir, escribir "$foo", a menos que comprenda por qué necesita la división de palabras en un caso de uso particular. (Tenga en cuenta que las expansiones de variables desnudas también se someten a globbing).
En este caso específico de Zsh, la división de palabras se define de manera ligeramente diferente a la división de campos.
Considerar prog a b c, pasará tres argumentos sin importar cómo establezca IFS. Este es palabra terrible.
Si lo haces A="a b c"; prog $A, pasará tres argumentos si IFS incluye espacio o un argumento en caso contrario. Este es campo terrible.
Las definiciones aquí son sutiles. Lo que el documento Zsh está tratando de decir es que, incluso si deshabilita esa opción, prog a b c seguirá obteniendo argumentos separados (que es lo que la gente siempre espera).
La división de palabras no es realmente específica de la shell.
La mayoría de los programas que necesitan analizar la entrada de texto utilizan alguna forma de división de palabras como primer paso. Se hace antes de identificar a partir de estas “palabras”, números, operadores, cadenas, tokens y cualquier entidad similar que necesiten procesar.
Lo que es específico con los shells es que tienen que construir correctamente la lista de argumentos de los comandos llamados (C argc / argv, python sys.argv), incluido el paso de argumentos con espacios incrustados, argumentos vacíos, delimitadores personalizados, etc. Muchos shells usan la variable IFS para permitir cierta flexibilidad allí.