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


11

¿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.


77
Es una distinción de clase versus instancia.
Kaz

1
Material de lectura interesante: unix.stackexchange.com/questions/4126/…
Bernhard

1
El primer caparazón fue escrito por un tipo llamado Bourne. BASH es un acrónimo de 'Boune Again Shell'. ¡Es importante divertirse!
Kinjal Dixit

Respuestas:


31

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 .


3
Finder no suele llamarse shell en OS X. La mayoría de las funciones de administración de ventanas y GUI son manejadas por otros procesos.
Lri

1
@LauriRanta Wikipedia parece estar en desacuerdo . Independientemente de si tiene o no ayuda de otros procesos, su trabajo es permitir que el usuario interactúe con el sistema operativo subyacente a través de una GUI y, por lo tanto, se ajusta a la descripción de un shell gráfico.
Indrek

1
Supongo que el término shell gráfico también puede aplicarse a las aplicaciones de gestión de archivos. Pero generalmente no se usa en OS X, y Finder se parece más a Nautilus que el shell de Windows o Unity.
Lri

66
@LauriRanta: cuestionario rápido, ¿cuál es el ícono de Nautilus?
Lie Ryan

2
@LauriRanta ¿Dock no sería un mejor candidato para un shell? El lanzamiento de programas y documentos de apertura, Expose / Spaces / Mission Control, AFAIK Launchpad y el selector de tareas también son todas las características de Dock.
Daniel Beck

13

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.


2
Los shells no están necesariamente basados ​​en la línea de comandos, también hay muchos shells gráficos, por ejemplo, Nautilus, Windows Explorer, Finder, etc. es decir, shells proporciona gestión de recursos (por ejemplo, gestión de archivos) y gestión de procesos.
Lie Ryan

1
@LieRyan esos no son shells, son administradores de archivos. Los shells permiten que los intérpretes de comandos / scripts integrados se ejecuten dentro de ellos. Mira mi respuesta. El solo hecho de poder ejecutar un programa desde un administrador de archivos no lo convierte en un shell.
Bill Rosmus

@BillR: Deberías informar a los chicos de Gnome Shell de tu definición.
Paradroid

2
Me inclino a estar de acuerdo con Lie Ryan y paradroid, que las conchas gráficas ahora se consideran conchas. Estoy tan involucrado en el paradigma de la línea de comandos como cualquier otra persona y me resistí a aceptar shells gráficos como shells durante los años 90. Pero con todos los widgets del panel de control y demás en un shell gráfico moderno, ahora estoy de acuerdo en que el uso común es llamarlos shells y que ese uso es correcto. Coinciden con la definición de un shell, una capa de interfaz de usuario relativamente delgada alrededor del sistema operativo subyacente. Los shells gráficos son más débiles sobre cómo alguien escribiría un script, pero a muchos usuarios no les importa eso.
Nicole Hamilton

6

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.


2

Shell es una interfaz de usuario basada en texto.

Bash es un tipo de concha.


2
¿Qué es una "interfaz de usuario basada en prueba"? También sería bueno expandir un poco su respuesta. Como puede ver en las otras respuestas, siempre ayuda dar más contexto.
slhck

Lo siento. Interfaz de usuario basada en texto. ¿Cómo le gustaría que yo lo expusiera? Un shell es su forma de línea de comandos de interactuar con el núcleo del sistema operativo. ¿Shell interpreta sus comandos y los transmite a la máquina que luego, a su vez, realiza las operaciones necesarias relevantes para el comando que ha dado? Sin un manual de 500 páginas, es difícil exponer efectivamente esta pregunta ambigua. El esfuerzo de la respuesta se ajusta al esfuerzo de la pregunta. Esta pregunta es de manzanas a naranjas.
HayekSplosives

Si cree que una pregunta muestra ahora un esfuerzo que no significa automáticamente que no debe poner esfuerzo en una respuesta. Su respuesta, en comparación con las demás, carece de un pequeño detalle. Por supuesto, depende de usted agregar eso.
slhck

Agradezco la corrección y la lección de responsabilidad personal. Gracias por proteger a aquellos que no están dispuestos a poner el esfuerzo de aquellos que lo hacen. Estoy totalmente fuera de lugar olvidando cuánto le debía al póster.
HayekSplosives


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.