¿IFS nulo no es lo mismo que IFS no configurado?

Leí una gran pregunta aquí llamada Understanding IFS . Me sorprendió porque las respuestas y los comentarios citan POSIX que dice que IFS = no es lo mismo que desestabilizar IFS. Si desarma IFS, aparentemente se usa el valor predeterminado. Si hace que IFS sea nulo, no hay divisor. Sabía que había visto una versión diferente de eso, y lo encontré en mis marcadores:

Programación Bourne Shell

$ IFS

La primera declaración en su script debería ser

IFS =

que restablece el separador de campo de entrada a su valor predeterminado. De lo contrario, heredará $ IFS del usuario, que puede haberlo establecido en un valor extraño para hacer que las cadenas de análisis se diferencien de la forma esperada e induzcan un comportamiento extraño.

Entonces, ¿eso era cierto hace algún tiempo o el autor está equivocado?

Las respuestas que encontró en Stack Exchange son correctas y este tutorial es incorrecto. Puede experimentar solo o buscarlo en el estándar . Un desarmado IFSes equivalente a establecerlo en el valor predeterminado de space-tab-newline, mientras que un vacío IFSdesactiva efectivamente la división del campo.

Puede consultar la página de Sven Mascheck en IFS sobre implementaciones históricas. A algunos shells históricos no les gustó unset IFS, y una versión muy antigua de ksh lo trataba como un vacío, IFSpero todos los shells modernos y la mayoría de los shells antiguos tratan un valor no establecido IFScomo el valor predeterminado.

No debe comenzar su secuencia de comandos a IFS=menos que desee desactivar la división de campos (lo cual puede ser una decisión razonable, pero tenga en cuenta que todavía necesita poner comillas dobles alrededor de las sustituciones para evitar el engorde, a menos que también lo desactive set -f). Para restablecer el valor predeterminado, use unset IFS. Es discutible si esto es útil al comienzo de un script; Hay muchas otras cosas malas, como un error PATHque la persona que llama puede hacer para que su guión salga mal.

Este tutorial también aconseja reiniciar PATH. Esto suele ser un mal consejo. En la mayoría de los casos, no puede predecir cuál es la ruta de búsqueda correcta, pero el usuario lo sabe. ¿Cómo saber si contiene /usr/local/bino /home/bob/bincontiene versiones de utilidades con corrección de errores en un antiguo Unix donde las que /usr/binestán en buggy? ¿Realmente quieres incrustar toda la lógica para decidir si poner /usr/xpg6/bindelante /bin? ¿En qué posición quieres /usr/gnu/bin? No restablezca la RUTA a menos que su script apunte a un sistema específico.

No he leído este tutorial, pero verifiqué una cosa: no te dice desde el principio que siempre pongas comillas dobles alrededor de sustituciones variables y sustituciones de comandos. Así que no creo que este tutorial sea bueno.