Technology · GUÍA PRÁCTICA
¿Shell dice “bad substitution”? Pruebe el intérprete y la familia sintáctica antes de reescribir
Fije el launcher real, el parser y su versión, clasifique la expansión, elija Bash o sh portátil y repita la ruta original.
“Bad substitution” no demuestra que la expresión sea incorrecta. Una expansión Bash válida falla si la analiza sh, dash, un Bash antiguo, el shell que hace source o un wrapper; ${command ...} mal formado falla incluso en Bash.
Conserve comando y stderr, demuestre ruta e intérprete efectivo, clasifique el token según el contrato, cambie una rama y repita el mismo launcher con una entrada fija.
1. Fije la ruta y el primer error
Registre comando, wrapper/scheduler, cwd, nombres de entorno, path, primer stderr y estado; distinga direct, bash, sh, source y pipe.
No empiece cambiando /bin/sh, quitando el shebang o reemplazando todo: borraría la prueba de selección del parser.
2. Pruebe intérprete y nivel de funciones
Capture procesos padre/hijo, shell del wrapper y versión; $SHELL no prueba el parser actual.
El shebang funciona al ejecutar directamente un script executable; source, sh -c, CI y cron obedecen al caller.
3. Clasifique la expresión
Separe parameter expansion portátil de replacement, substring, case y arrays de Bash; verifique el operador exacto en el manual.
${ls ...} confunde parameter expansion con command substitution. Use $(...) y no eval.
4. Elija un contrato explícito
Si requiere Bash, configure wrappers y scheduler para el Bash previsto y compruebe versión cuando sea necesaria.
Si requiere POSIX sh, sustituya sintaxis Bash-only por una forma respaldada por la norma; no mezcle contratos.
5. Verifique con el launcher original
Pruebe un fixture fijo con dash -n, bash -n, Bash de producción y el wrapper real; registre path, versión, estado, stdout y stderr.
Acepte solo cuando la ruta original produzca la salida esperada; si direct/source difieren, declare contratos separados.
