¿Cuál es la diferencia entre los términos "Shell" y "Bash"?

¿Cuál es la diferencia entre "Shell" y "Bash" y qué significan estos términos?

Que yo sepa, no hay diferencia. ¡Pero he visto muchos libros sobre "Shell" y otros sobre "Bash"!

Entonces, en caso de que quiera trabajar con la Terminal en Mac OS X y escribir algunos scripts de bash, me pregunto qué tipo de libros debería buscar.

Un " shell " es cualquier software que proporciona una interfaz a un sistema operativo. Por ejemplo, explorer.exe es el shell predeterminado en Windows (aunque existen alternativas ), y en OS X Finder proporciona casi la misma funcionalidad. En Linux / * nix, el shell podría ser parte del entorno de escritorio (como Gnome o KDE ), o puede ser un componente de software separado que se encuentra encima (como Unity o Cinnamon ).

Los ejemplos anteriores son todos los shells gráficos que usan una combinación de ventanas, menús, iconos y otros elementos similares para proporcionar una interfaz gráfica de usuario (GUI) con la que se puede interactuar usando el cursor del mouse. Sin embargo, en el contexto de software como Bash, o escribir scripts, "shell" generalmente se entiende como un intérprete de línea de comandos, que realiza en gran medida las mismas funciones que un shell gráfico, excepto que está completamente basado en texto.

Bash es un ejemplo específico de un shell de línea de comandos, y es probablemente uno de los más conocidos, siendo el predeterminado en muchas distribuciones de Linux, así como en OS X. Fue diseñado como un reemplazo para el shell Bourne (Bash significa para "Bourne again shell"), uno de los primeros shells de Unix .

Ejemplos de shells de línea de comandos en Windows incluyen cmd.exe (también conocido como Símbolo del sistema) y PowerShell .

Bash es una de varias conchas.

Un shell en un sistema similar a Unix o Unix como OSX o Linux es un programa de aplicación que proporciona una interfaz de línea de comandos para el sistema operativo, lo que le permite escribir comandos y ejecutarlos. Hay una variedad de shells diferentes para elegir, pero todos proporcionan comodines de nombre de archivo, tuberías, aquí documentos, sustitución de comandos, variables y estructuras de control para pruebas de condición e iteración.

El shell original de Unix era el shell Bourne , sh, escrito por Stephen Bourne en Bell Labs. Luego vino el shell C , escrito por Bill Joy en Berkeley, ya actualizado como tcsh . Otros shells incluyen Korn shell , ksh, escrito por David Korn, también en Bell Labs, y bash , "Bourne again shell", escrito por Brian Fox para el proyecto GNU como reemplazo gratuito de sh.

Hoy en día, bash es probablemente el shell de Unix más popular, pero mucha gente (incluido yo) todavía prefiere el shell C basado en (lo que para algunos de nosotros parece) su sintaxis más agradable. Básicamente, es cuestión de gustos, por lo que recomiendo leer los artículos de Wikipedia que he vinculado para ayudarlo a comenzar.

El término 'shell' está bien nombrado. Es literalmente un caparazón alrededor del O / S que permite al usuario interactuar con la computadora. Cuando se concibió originalmente, había muy poca o ninguna interfaz gráfica de usuario (sin ventanas :(). Todo se hizo en la línea de comando. Pero incluso la línea de comando necesitaba un lugar para vivir. Vivía, y aún lo hace, en un shell .

En términos simples, para que la línea de comando sea útil, necesitaba instrucciones a las que pudiera llamar. Por lo tanto, los programas se ejecutaron dentro del shell para que la línea de comando los utilizara. Los programas se agruparon estrechamente en sus propios paquetes y tenían la intención de trabajar juntos. Incluyen programas como "ls" y "grep", "ps", "sed", etc. También incluyen comandos de redirección de archivos como ">" y "<" y tuberías ("|"). Más importante aún, también incluyen construcciones de programación como operaciones condicionales (si, entonces, de lo contrario, para bucles, mientras que bucles, formas de verificar el estado devuelto cuando ejecuta una instrucción (por ejemplo, si ejecuta "ls", ¿encontró algo?) como eso). Estos son los fundamentos de los scripts de línea de comandos (shell) más complejos,

Cuando alguien usa el término 'Bash Shell' está hablando de un intérprete de línea de comando llamado 'Bash' que se ejecuta en el shell O / S. Se podría pensar que es la abreviatura de 'Bash Shell Interpreter'. Hay otros intérpretes como Bourne (Bash es un nuevo y mejorado Bourne Shell y es la abreviatura de Bourne Again Shell). También está el C-Shell, el K-Shell (favorecido por muchos que escriben scripts de shell complejos) y otras variantes de GNU. A lo largo de los años, se ha vuelto habitual consultar el intérprete de línea de comandos particular que está utilizando como shell porque uno no se puede usar sin el otro. Pero la realidad es que son diferentes.

En cuanto a por qué se los conoce correctamente como intérpretes de línea de comandos y no como el shell real: es porque viven en el shell e interpretan todos los comandos como si se estuvieran ejecutando en un programa. Y al shell no le importa qué intérprete ejecute, siempre que cumpla con los estándares correctos.

Y en cuanto a por qué se les llama intérpretes, es porque realmente son intérpretes. Incluso si no está ejecutando explícitamente un script (y un script es realmente solo un archivo de texto de comandos que crea para que pueda ejecutar los mismos comandos una y otra vez sin tener que volver a escribirlos). Por ejemplo, tome el humilde comando 'ls'. Cuando lo ejecuta, devuelve una lista de archivos. Pero cómo se ejecuta es más importante para su pregunta: en realidad se ejecuta dentro del contexto del intérprete de línea de comandos, incluso si solo ejecuta lo que parece ser un simple comando de apagado. Es decir, se ejecuta como si fuera una declaración en parte de un programa más grande. Se ejecuta como si estuviera en un archivo de script de script de shell sin estar realmente en un archivo de script de shell. Un archivo de script de shell anónimo, por así decirlo.

Todo lo que ejecute en la línea de comandos tiene esto en común (ya sea un comando único como 'ls' o un archivo de script lleno de comandos e iteradores y declaraciones condicionales): todo es procesado por el intérprete de línea de comandos; ya sea Bash, C-Shell, K-Shell (predeterminado en AIX por cierto).

Para ver a qué me refiero, haga un directorio 'prueba':

mkdir test

Ingrese y ejecute los siguientes comandos

grep hello * 

Obtendrá algún tipo de respuesta como 'no existe tal archivo o directorio'. Ahora ingrese el comando

echo $?

($? dice, dime qué encontraste en la computadora críptica.) Deberías ver que devuelve un número (debería ser) '2'. Ese es el código de retorno de grep que significa 'no existe tal archivo o directorio'. Ahora ejecuta lo siguiente:

echo hello > hello.txt
grep hello *
echo $?

Verá el archivo 'hello.txt' devuelto por el comando grep inicial y ahora debería ver el 'echo $?' devuelve el número '0', lo que significa que realmente encontró algo.

Incluso si se ejecutan estos comandos aparentemente únicos, el intérprete de línea de comandos actúa como si fueran parte de un programa más grande y realiza un seguimiento de sus valores de retorno. Es por eso que si olvida el * al final del comando grep, no regresa. Se sabe que la declaración está incompleta y espera más información. Después de todo, posiblemente podría pedirle que tome los resultados de algún bucle que es perfectamente legal escribir y ejecutar en la línea de comando.

La conclusión es que el shell es el shell, y el intérprete (cualquiera que sea el nombre del que usa, 'Bash', k-shell, etc.) es diferente. Pero a menudo se usan indistintamente, porque en cualquier instante están completamente unidos.

Shell es una interfaz de usuario basada en texto.

Bash es un tipo de concha.

bashes de la shellfamilia, pero hay muchas otras conchas.

Por ejemplo, en Minix3 , está el ashshell, no admite matrices asociativas como bash4.

El estándar POSIX es un intento de hacer una API portátil entre diferentes shells y sistemas operativos.

Ver http://en.wikipedia.org/wiki/Unix_shell#Bourne_shell_compatible

bash Es uno de los muchos depósitos que existen.

Todos los proyectiles tienen sus similitudes y diferencias. Por ejemplo, una secuencia de comandos escrita en bash podría ser total o totalmente compatible con otro shell (por ejemplo, zsh ).

Debido al hecho de que bashestá muy extendido, a menudo se implica que un script es compatible con él.

Si está buscando comprar un libro, compre uno escrito específicamente para el shell que pretende usar. Sin embargo, sería una buena idea leer sus diferencias antes de gastar dinero.