SHELL="/bin/bash" frente a SHELL="bash"

Question

¿Cuál es la diferencia entre exportar SHELL="/bin/bash" y SHELL="bash"? Anteriormente tenía export SHELL="bash"en mi .bashrc. Pareció funcionar. $($SHELL) generó un subshell, pero ssh con autenticación de clave pública dio el error:Shell "bash" is not executable: No such file or directory

Answer 1

$($SHELL)generó una subcapa

Sí, porque en un caparazón $SHELL(omejor "$SHELL") se expande a /bin/basho bash, en su caso, a ambos engendran Bash.

^{Nota al margen: cuando usa $($SHELL), la salida proveniente del nuevo shell se ejecutará después de que el shell salga porque así es como $( … )funciona el comando de sustitución ( ). Sustitución de mandotiene poco sentidoaquí y no es necesario para mostrar su punto.}

Su punto parece ser: cuando SHELL="bash"ejecuta "$SHELL"Bash, alguna otra herramienta (¿servidor SSH?) se queja.

No está claro qué herramienta se queja. Y no nos dijo si SHELLfue manipulado en el lado del cliente o en el lado del servidor. No haymcveen la pregunta. Tampoco está claro por qué es necesario SHELLconfigurar .bashrc. No voy a investigar ninguno de estos.

Te voy a hablar de SHELLla diferencia entre /bin/bashybash en general.

El propósito de la SHELLvariable de entorno es apuntar al shell que desea utilizar. Varios programas pueden usar la variable (si está configurada) para intentar ejecutar el shell elegido por cualquier motivo. La diferencia que observó ocurre porque algunos programas se basan en elPATHVariable ambiental, algunos no.

La dependencia de PATHfunciona de la siguiente manera. Hay una cadena que "codifica" qué ejecutable ejecutar. Por ejemplo, la cadena puede ser /bin/bash, foo/basho bash. Hay dos casos:

1. Si la cadena contiene, /entonces la cadena misma se interpreta como una ruta absoluta (p. ej. /bin/bash) o relativa (p. ej. foo/bash) al ejecutable.
2. Si la cadena no contiene /(por ejemplo bash), solo especifica el nombre base del ejecutable. El resto de la ruta (es decir, los componentes del directorio) proviene de PATH. Básicamente, es el primer directorio especificado PATHque contiene un ejecutable con el nombre base especificado. Dependiendo de PATH, bashse puede resolver como /bin/bash, /home/you/bin/bash, ./bash(casi nunca) o nada en absoluto (dando usted command not foundo un error similar).

Los shells dependen PATH, por lo tanto, en un shell bash(escrito literalmente o que aparece a partir de la expansión de $SHELLo lo que sea) se encuentra /bin/basho /some/other/path/to/bashen un sistema correctamente configurado.

Las herramientas que no dependen de PATHtratan la cadena como una ruta (nombre de ruta). Esto no hace ninguna diferencia para una cadena que contiene /. Hace una gran diferencia para una cadena que no contiene /. Si la cadena es bashy se interpreta directamente como una ruta, es equivalente a ./bashlo que significa "archivo nombrado bashen el directorio de trabajo actual".

Lo que sea que le dio el error aparentemente recuperó el contenido de la SHELLvariable y lo usó como ruta sin depender de la PATHvariable.

Esto era lo correcto. Nota POSIXespecificaSHELLcomo:

Esta variable representará un nombre de ruta del intérprete de lenguaje de comandos preferido del usuario.

Investigar "nombre de ruta" y "resolución de nombre de ruta", estos no dependen de PATH. Cualquier herramienta que utilice la SHELLvariable tratará su contenido directamente como un nombre de ruta.

Cuando SHELL="bash", en un shell "$SHELL"ejecuta Bash solo porque $SHELLse expandecomo cualquier otra variabley luego bashes tratadocomo cualquier otro comando que no contenga/. Entonces es un poco incidental.

Si interpreto correctamente la documentación POSIX, debería usarla SHELL="bash"solo si quiere decir SHELL="./bash". Incluso si te refieres a esto, es mejor usar una ruta con /, de modo que la mecánica en un shell donde PATHse puede usar no interfiera con la forma en que SHELLse interpretará.

Lo más probable es que no quieras ./bash. Quieres /bin/bashusar exactamente esto.