Estoy intentando trabajar con una biblioteca de código existente pero he encontrado un problema. En resumen, ejecuto un script de shell (llamemos a esteA) cuyoprimer acto es llamar a otro script (B) GuiónB está en mi directorio actual (un requisito del programa que estoy usando). El manual del software hace referencia abash, sin embargo comentarios enA sugieren que fue desarrollado enksh. He estado operando enbash hasta aquí.

DentroA, la línea a ejecutarB es simple:

. B

Utiliza la sintaxis de "espacio de puntos" para llamar al programa. No hace nada inusual comosudo.

Cuando llamoA sin sintaxis de espacio de puntos, es decir:

./A

siempre errores diciendo que no puede encontrar el archivoB. yo añadípwd, ls, whoami, echo $SHELLyecho $PATH líneas aA depurar y confirmó queB de hecho está ahí, el script se ejecuta con el mismo$SHELL como estoy en el símbolo del sistema, el script es el mismo usuario que yo y el script tiene la misma ruta de búsqueda$PATH como yo lo hago. También verifiqué si hago:

. B

en la línea de comando, funciona bien. Pero si cambio la sintaxis dentroA a:

./B

en cambio, entoncesA se ejecuta con éxito

Del mismo modo, si ejecutoA con sintaxis de espacio de puntos, entonces ambos. B y./B trabajo.

Resumiendo:
./A solo funciona siA contiene./B sintaxis.
. A trabaja paraA con cualquiera./B o. B sintaxis.

Entiendo que usar el espacio de puntos (es decir. A) la sintaxis se ejecuta sin bifurcar a una subshell, pero no veo cómo esto podría resultar en el comportamiento que estoy observando dado que el archivo está claramente allí. ¿Hay algo que me falta sobre los matices de la sintaxis o los espacios de trabajo de proceso padre / hijo? ¿Magia?

ACTUALIZACIÓN1: Se agregó información que indica que el script puede haberse desarrollado enksh, mientras estoy usandobash.
ACTUALIZACIÓN2: Se agregó una verificación para verificar$PATH es el mismo.

ACTUALIZACIÓN3: El guión dice que fue escrito paraksh, pero se está ejecutando enbash. En respuesta a la respuesta de Kenster, encontré que correrbash -posix entonces. B falla en la línea de comando. Eso indica que la diferencia en los entornos entre la línea de comando y el script es que este último se está ejecutandobash en un modo compatible con POSIX, mientras que la línea de comando no lo es. Mirando un poco más cerca, veo esto en elbash man página:

Cuando se invoca como sh, bash ingresa al modo posix después de leer los archivos de inicio.

losshebang paraA es de hecho#!/bin/sh.

En resumen, cuando corroA sin sintaxis de espacio de puntos, se bifurca a su propia subshell, que está en modo compatible con POSIX porque elshebang es#!/bin/sh (en lugar de, por ejemplo,#!/bin/bash. Esta es la diferencia crítica entre la línea de comandos y los entornos de tiempo de ejecución de script que conduce aA ser incapaz de encontrarB.