zsh como shell predeterminado de macOS: qué falla en un script escrito para bash

Qué es

La documentación de soporte de Apple indica que, desde macOS 10.15, zsh es el shell de inicio de sesión e interactivo predeterminado en las cuentas recién creadas; las cuentas heredadas de 10.14 o anteriores pueden seguir teniendo bash como shell de inicio de sesión (se comprueba con dscl . -read ~ UserShell). Por eso, un agente que abre una sesión tipo Terminal en un Mac suele estar en zsh, aunque /bin/bash sigue presente para los scripts que lo nombran en el shebang. Ese /bin/bash está congelado en la versión 3.2.57, la última publicada bajo GPLv2; bash 4.0 y posteriores usan GPLv3, licencia que Apple no distribuye.

Por qué importa

Las opciones predeterminadas de zsh difieren de las de bash/POSIX sh de maneras que cambian el resultado de código que, a primera vista, es idéntico:

• División de palabras: la opción SH_WORD_SPLIT de zsh, que según el manual de zsh hace que «se realice la división en campos de las expansiones de parámetros sin comillas», está desactivada por defecto. Un $var sin comillas que contenga espacios sigue siendo una sola palabra en zsh (interactivo o en script), a diferencia de bash, donde se divide; la salida de $(...) sin comillas sí se sigue dividiendo. El código portado desde bash que depende de esa división (un modismo antiguo de bash/sh) no hace nada, sin avisar, en zsh sin configurar.
• Los arrays empiezan en 1: por defecto zsh numera los elementos de un array desde 1; la opción KSH_ARRAYS cambia a la convención de bash/ksh, que según el manual hace que «los elementos del array... se numeren desde cero». El código que supone que arr[0] es el primer elemento lee el elemento equivocado, o uno vacío, con zsh por defecto.
• Errores de glob en lugar de una cadena literal: con las opciones predeterminadas de zsh, un patrón que no coincide con nada activa el comportamiento NOMATCH, que según la documentación consiste en mostrar «un error, en lugar de» dejar el patrón sin cambios; bash, en cambio, pasa al comando el patrón literal sin expandir, salvo que estén activadas nullglob o failglob. Un script que asume el comportamiento predeterminado de bash puede abortar en zsh por un glob que simplemente no coincidió con nada.

Cómo aplicarlo

• Pon un shebang explícito (#!/bin/bash o #!/bin/zsh) en todos los scripts en lugar de depender del shell de inicio de sesión, y ejecútalos con bash script.sh en vez de cargarlos con source en una sesión interactiva de zsh cuando se necesite la semántica de bash.
• Si un script debe funcionar correctamente en ambos shells, pon entre comillas cada expansión de parámetro ("$var") para que las diferencias en la división de palabras no importen, evita suponer arrays con índice 0 o prueba con ambos intérpretes.
• Trata /bin/bash en macOS como una compilación heredada 3.2: es anterior a los arrays asociativos, a mapfile y a otras funciones de bash 4+; si las necesitas, instala un bash actual con un gestor de paquetes y refiérete a él por su ruta completa, ya que /bin/bash no va a cambiar.

Trampas

• Asumir que "un Mac es básicamente Linux/bash" y pegar un script específico de bash, sin shebang, en el shell predeterminado de un agente en macOS.
• Probar solo en un zsh configurado de forma interactiva (con un .zshrc personalizado que active KSH_ARRAYS o SH_WORD_SPLIT) y entregar un script que falla con un perfil predeterminado limpio.
• Olvidar que /bin/sh en macOS es, por defecto, bash 3.2 ejecutándose en modo POSIX (desde 10.15 se resuelve mediante /private/var/select/sh, que puede reenlazarse a dash o zsh), con valores de opciones distintos tanto de zsh interactivo como del bash habitual.