Qual é a diferença entre os termos "Shell" e "Bash"?


11

Qual é a diferença entre "Shell" e "Bash" e o que esses termos significam?

Até onde eu sei, não há diferença. Mas eu já vi muitos livros sobre "Shell" e outros sobre "Bash"!

Portanto, caso eu queira trabalhar com o Terminal no Mac OS X e escrever alguns scripts bash, estou pensando em que tipo de livros devo procurar.


7
É uma distinção de classe versus instância.
Kaz

1
Material de leitura interessante: unix.stackexchange.com/questions/4126/…
Bernhard

1
a primeira concha foi escrita por um cara chamado Bourne. BASH é um acrônimo para 'Boune Again Shell'. É importante se divertir!
Kinjal Dixit

Respostas:


31

Um " shell " é qualquer software que fornece uma interface para um sistema operacional. Por exemplo, explorer.exe é o shell padrão no Windows (apesar de existirem alternativas ) e no OS X Finder fornece praticamente a mesma funcionalidade. No Linux / * nix, o shell pode fazer parte do ambiente de área de trabalho (como Gnome ou KDE ), ou pode ser um componente de software separado em cima (como Unity ou Cinnamon ).

Os exemplos acima são todos shells gráficos que usam uma combinação de janelas, menus, ícones e outros elementos para fornecer uma interface gráfica do usuário (GUI) que pode ser interagida com o uso do cursor do mouse. No entanto, no contexto de software como o Bash, ou escrever scripts, "shell" geralmente é interpretado como um intérprete de linha de comando, que executa basicamente as mesmas tarefas que um shell gráfico, exceto que é inteiramente baseado em texto.

O Bash é um exemplo específico de shell de linha de comando e provavelmente é um dos mais conhecidos, sendo o padrão em muitas distribuições Linux e no OS X. Ele foi projetado como um substituto para o shell Bourne (o Bash significa para "Bourne again shell"), uma das primeiras conchas do Unix .

Exemplos de shells de linha de comando no Windows incluem cmd.exe (também conhecido como Prompt de Comando) e PowerShell .


3
O Finder geralmente não é chamado de shell no OS X. A maioria dos recursos de gerenciamento de GUI e janelas é tratada por outros processos.
Lr 15/10/12

1
A @LauriRanta Wikipedia parece discordar . Independentemente de ter ou não ajuda de outros processos, seu trabalho é permitir que o usuário interaja com o SO subjacente por meio de uma GUI e, portanto, se encaixa na descrição de um shell gráfico.
Indrek

1
Eu acho que o termo shell gráfico também pode se aplicar a aplicativos de gerenciamento de arquivos. Mas geralmente não é usado no OS X, e o Finder é mais parecido com o Nautilus do que com o shell do Windows ou o Unity.
Lri

6
@LauriRanta: teste rápido, qual é o ícone do Nautilus?
Lie Ryan

2
@LauriRanta O Dock não seria um candidato melhor para um shell? Programas de inicialização e documentos de abertura, Expose / Spaces / Mission Control, AFAIK Launchpad e o alternador de tarefas também são todos os recursos do Dock.
Daniel Beck

13

Bash é uma das várias conchas.

Um shell em um sistema Unix ou semelhante ao Unix, como OSX ou Linux, é um programa aplicativo que fornece uma interface de linha de comando para o sistema operacional, permitindo digitar comandos e executá-los. Há vários shells diferentes para escolher, mas todos eles fornecem curingas de nome de arquivo, canalização, documentos aqui, substituição de comandos, variáveis ​​e estruturas de controle para teste de condição e iteração.

O shell Unix original era o shell Bourne , sh, escrito por Stephen Bourne no Bell Labs. Depois veio o shell C , escrito por Bill Joy em Berkeley, desde que atualizado como tcsh . Outros shells incluem o Korn shell , ksh, escrito por David Korn, também no Bell Labs, e o bash , o "Bourne again shell", escrito por Brian Fox para o projeto GNU como um substituto gratuito do sh.

Hoje, o bash é provavelmente o shell Unix mais popular, mas muitas pessoas (inclusive eu) ainda preferem o shell C com base em (o que para alguns de nós parece) sua melhor sintaxe. Basicamente, é uma questão de gosto, por isso recomendo a leitura dos artigos da Wikipedia que vinculei para ajudar você a começar.


2
Os shells não são necessariamente baseados em linha de comando; também existem muitos shells gráficos, por exemplo, Nautilus, Windows Explorer, Finder etc. O ponto essencial para o shell é que ele é um wrapper / interface do usuário / shell em torno das principais funcionalidades do SO / chamadas do sistema, isto é, shells fornece gerenciamento de recursos (por exemplo, gerenciamento de arquivos) e gerenciamento de processos.
Lie Ryan

1
@LieRyan não são conchas, são gerenciadores de arquivos. Os shells permitem que intérpretes de comando / script integrados sejam executados dentro deles. Veja minha resposta. Ser capaz de executar um programa a partir de um gerenciador de arquivos não o torna um shell.
Bill Rosmus

@ BillR: Você deve informar os caras do Gnome Shell sobre sua definição.
Paradroid 19/10

2
Estou inclinado a concordar com Lie Ryan e paradroid, que as conchas gráficas agora são consideradas conchas. Estou tão investido no paradigma da linha de comando quanto qualquer um e resisti a aceitar conchas gráficas como conchas nos anos 90. Mas com todos os widgets do painel de controle e outros enfeites em um shell gráfico moderno, agora concordo que o uso comum é chamá-los de conchas e que esse uso está correto. Eles correspondem à definição de shell, uma camada de interface do usuário relativamente fina em torno do SO subjacente. Os shells gráficos são mais fracos sobre como alguém escreveria algo, mas muitos usuários não se importam com isso.
Nicole Hamilton

6

O termo 'shell' é bem nomeado. É literalmente um shell em torno do sistema operacional, permitindo que o usuário interaja com o computador. Quando foi originalmente concebido, havia muito pouca ou nenhuma interface gráfica de usuário (sem janelas :(). Tudo foi feito na linha de comando. Mas até a linha de comando precisava de um lugar para morar. Vivia, e ainda o faz, em um shell .

Em termos simples, para que a linha de comando seja útil, ele precisava de instruções que pudesse chamar. Assim, foram criados programas para serem executados dentro do shell para a linha de comando usar. Os programas foram agrupados firmemente em seus próprios pacotes e pretendiam trabalhar juntos. Eles incluem programas como "ls" e "grep", "ps", "sed" etc. Eles também incluem comandos de redirecionamento de arquivos como ">" e "<" e pipes ("|"). Mais importante, eles também incluem construções de programação como operações condicionais (se, então, para loops, enquanto loops, maneiras de verificar o status retornado quando você executa uma instrução (por exemplo, se você executar "ls", encontrou alguma coisa?)), Coisa Curtiu isso). Estes são os fundamentos de scripts de linha de comando (shell) mais complexos,

Quando alguém usa o termo 'Bash Shell', eles estão falando sobre um interpretador de linha de comando chamado 'Bash' que é executado no shell O / S. Você pode pensar nisso como abreviação de 'Bash Shell Interpreter'. Existem outros intérpretes como Bourne (Bash é um 'Bourne Shell novo e aprimorado e é a abreviação de Bourne Again Shell). Há também o C-Shell, o K-Shell (preferido por muitos que escrevem scripts de shell complexos) e outras variantes do GNU. Ao longo dos anos, tornou-se habitual consultar o interpretador de linha de comando específico que você está usando como shell, porque um não pode ser usado sem o outro. Mas a realidade é que eles são diferentes.

Por que eles são conhecidos como intérpretes de linha de comando e não como o shell real: é porque eles vivem no shell e interpretam todos os comandos como se estivessem rodando em um programa. E o shell não se importa com qual intérprete você executa nele, desde que atenda aos padrões corretos.

E por que eles são chamados de intérpretes, é porque eles são realmente intérpretes. Mesmo se você não estiver executando explicitamente um script (e um script for realmente apenas um arquivo de texto dos comandos criados para poder executar os mesmos comandos repetidamente, sem precisar digitá-los novamente). Por exemplo, tome o humilde comando 'ls'. Quando você o executa, ele retorna uma lista de arquivos. Mas como é executado é mais importante para a sua pergunta: ele realmente é executado dentro do contexto do interpretador de linha de comando, mesmo se você apenas executar o que parece ser um comando simples. Ou seja, é executado como se fosse uma declaração em parte de um programa maior. Ele é executado como se estivesse em um arquivo de script de script de shell sem realmente estar em um arquivo de script de shell. Um arquivo de script de shell anônimo por assim dizer.

Tudo o que você executa na linha de comando tem isso em comum (seja um comando único como 'ls' ou um arquivo de script cheio de comandos e iteradores e instruções condicionais): tudo é processado pelo interpretador da linha de comando; seja Bash, C-Shell, K-Shell (padrão no AIX btw).

Para entender o que quero dizer, faça um diretório 'test':

mkdir test

Digite-o e execute os seguintes comandos

grep hello * 

Você receberá algum tipo de resposta como "nenhum arquivo ou diretório". Agora digite o comando

echo $?

($? diz, diga-me o que encontrou no computador encriptado.) Você deve ver o número retornado (deve ser) '2'. Esse é o código de retorno do grep que significa 'não existe esse arquivo ou diretório'. Agora execute o seguinte:

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

Você verá o arquivo 'hello.txt' retornado do comando grep inicial e agora deverá ver o 'echo $?' retorne o número '0', o que significa que realmente encontrou algo.

Mesmo que esses comandos aparentemente únicos sejam executados, o interpretador de linha de comando age como se fosse parte de um programa maior e controla seus valores de retorno. É por isso que se você esquecer o * no final do comando grep, ele não retornará. É sabido que a declaração está incompleta e espera mais informações. Afinal, você poderia pedir para receber os resultados de algum loop, o que é perfeitamente legal para escrever e executar na linha de comando.

Bottom line é o shell é o shell, e o intérprete (qualquer que seja o nome daquele que você usa, 'Bash', k-shell, etc.) são diferentes. Mas muitas vezes são usados ​​de forma intercambiável, porque a qualquer instante eles estão completamente ligados.


2

Shell é uma interface de usuário baseada em texto.

Bash é um tipo de concha.


2
O que é uma "interface de usuário baseada em teste"? Também seria bom expandir um pouco sua resposta. Como você pode ver nas outras respostas, sempre ajuda a dar mais contexto.
slhck

Desculpe. Interface de usuário baseada em texto. Como você gostaria que eu expusesse isso? Um shell é sua maneira de interagir com o kernel do sistema operacional na linha de comando. O Shell interpreta seus comandos e os transmite para a máquina que, por sua vez, executa as operações necessárias relevantes para o comando que você deu? Sem um manual de 500 páginas, é difícil expor efetivamente essa questão ambígua. O esforço da resposta se encaixa no esforço da pergunta. Esta questão é de maçãs para laranjas.
HayekSplosives

Se você acha que agora uma pergunta mostra um esforço que não significa automaticamente que você não deve se esforçar para responder. Sua resposta, em comparação com as outras, carece de um pequeno detalhe. É claro que cabe a você adicionar isso.
Slhck 18/10/12

Agradeço a correção e a lição de responsabilidade pessoal. Obrigado por proteger aqueles que não estão dispostos a se esforçar daqueles que o fazem. Estou totalmente fora de linha esquecendo o quanto eu devia ao pôster.
HayekSplosives


1

bash é uma das muitas conchas que existem.

Todas as conchas têm suas semelhanças e diferenças. Por exemplo, um script escrito em bash pode ser total ou amplamente compatível com outro shell (por exemplo, zsh ).

Devido ao fato de bashser muito difundido, geralmente está implícito que um script é compatível com ele.

Se você deseja comprar um livro, compre um escrito especificamente para o shell que pretende usar. Seria uma boa idéia ler as diferenças antes de gastar dinheiro.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.