zsh como shell padrão do macOS: o que quebra em um script escrito para bash

O que é

A documentação de suporte da própria Apple afirma que, a partir do macOS 10.15, o zsh é o shell de login e interativo padrão para contas recém-criadas; contas migradas do 10.14 ou de versões anteriores ainda podem ter o bash como shell de login (verifique com dscl . -read ~ UserShell). Um agente que abre uma sessão do tipo Terminal em um Mac está, portanto, normalmente no zsh, embora o /bin/bash continue presente para scripts que o indicam no shebang. Esse /bin/bash está congelado na versão 3.2.57, a última sob a GPLv2; o bash 4.0 e posteriores usam a GPLv3, que a Apple não distribui.

Por que importa

O conjunto de opções padrão do zsh difere do bash/POSIX sh de maneiras que mudam o resultado de códigos aparentemente idênticos:

• Divisão de palavras: a opção SH_WORD_SPLIT do zsh, descrita no manual do zsh como causadora de "field splitting to be performed on unquoted parameter expansions", vem desativada por padrão. Um $var sem aspas que contenha espaços continua sendo uma única palavra no zsh (interativo ou em script), ao contrário do bash, em que ele é dividido; já a saída de $(...) sem aspas continua sendo dividida. Código portado do bash que depende dessa divisão (uma prática idiomática antiga de bash/sh) não faz nada, sem aviso, no zsh puro.
• Arrays começam em 1: por padrão, o zsh numera os elementos de um array a partir de 1; a opção KSH_ARRAYS muda para a convenção do bash/ksh, descrita no manual como fazendo com que "array elements... numbered from zero". Código que presume que arr[0] é o primeiro elemento lê o elemento errado, ou um vazio, no zsh padrão.
• Erro de glob em vez de string literal: com as opções padrão do zsh, um padrão que não corresponde a nada aciona o comportamento NOMATCH, documentado como exibir "an error, instead of" deixar o padrão inalterado; o bash, por sua vez, passa o padrão literal, sem expandir, ao comando, a menos que nullglob/failglob estejam definidos. Um script que presume o padrão do bash pode abortar no zsh por causa de um glob que simplesmente não encontrou nada.

Como aplicar

• Coloque um shebang explícito (#!/bin/bash ou #!/bin/zsh) em todo script, em vez de depender do shell de login, e execute os scripts com bash script.sh, em vez de carregá-los com source em uma sessão interativa do zsh, quando a semântica do bash for necessária.
• Se um script precisa funcionar corretamente nos dois shells, coloque aspas em toda expansão de parâmetro ("$var") para que as diferenças de divisão de palavras não importem, e evite suposições de arrays começando em 0 ou teste nos dois interpretadores.
• Trate o /bin/bash do macOS como uma versão 3.2 legada: ela é anterior aos arrays associativos, ao mapfile e a outros recursos do bash 4+; instale um bash atual por meio de um gerenciador de pacotes se precisar deles e referencie-o pelo caminho completo, já que o /bin/bash não vai mudar.

Armadilhas

• Presumir que "é um Mac, então é basicamente Linux/bash" e colar um script específico de bash, sem shebang, no shell padrão de um agente no macOS.
• Testar apenas em um zsh interativo configurado (com um .zshrc personalizado que define KSH_ARRAYS ou SH_WORD_SPLIT) e distribuir um script que falha com um perfil padrão limpo.
• Esquecer que o /bin/sh do macOS é, por padrão, o bash 3.2 em modo POSIX (desde o 10.15, ele é despachado por meio de /private/var/select/sh, que pode ser religado ao dash ou ao zsh), com padrões de opções distintos tanto do zsh interativo quanto do bash normal.