Por que o Terminal e o Shell são dois programas separados no Linux?

Question

No Windows, ao usar a CLI, apenas um programa é usado ( cmd.exe ). Você envia a entrada para cmd.exe e cmd.exe , por sua vez, envia a saída para você (exibe a saída na tela):

MasnoLinux,existemdoisprogramasquesãousados:oTerminaleoShell.

VocêenviaaentradaparaoTerminal(porexemplo:gnome-terminal)egnome-terminal,porsuavez,enviaessaentradaparaoShell(porexemplo:bash)e,emseguida,bashenviaasaídaparagnome-terminalegnome-terminal,porsuavez,enviamasaídaparavocê.

Minha pergunta é: Por que o Terminal e o Shell são dois programas separados no Linux e não um programa como no Windows?

    

Answer 1

Sua premissa é incorreta. O papel do "terminal" no Windows é jogado, mais ou menos, pelo conhost.exe - o subsistema do console não é projetado de forma a torná-lo intercambiável como os terminais estão no Linux (e há outras diferenças, por exemplo , quando você inicia um processo em modo de console, como cmd.exe, que ainda não está conectado a um console, as bibliotecas do sistema que iniciam o processo cuidarão da criação de um para você), mas é uma camada separada gerenciada por um processo separado.

    

Answer 2

Eu diria 1) por causa da história, 2) porque é uma boa ideia.

Geralmente chamamos gnome-terminal ou xterm um emulador de terminal . Nos tempos antigos, não havia emuladores de terminal, já que não havia interfaces gráficas com o usuário. Tudo o que havia eram terminais adequados, dispositivos com uma tela e um teclado conectados por meio de um cabo serial ao computador. As conchas também eram úteis e foram escritas para apoiar os comandos dos terminais. (Provavelmente de descritores de arquivos arbitrários, mas isso não importa.)

Com algo como terminais virtuais Linux e GUIs, era útil fazê-los emular os terminais originais, para que os antigos softwares pudessem funcionar, ou pelo menos com mudanças mínimas. Isso não significa apenas o shell, mas também outros programas que conectam o "terminal". ( ls ? vi ? emacs ?)

Além disso, a separação é uma boa idéia, pois permite trocar o emulador de terminal e o shell de forma independente. Eu posso usar Bash no xterm, ou zsh no gnome-terminal, ou Bash em uma conexão SSH, ou ...

Se as partes estivessem ligadas, essa escolha seria mais difícil.

Por acaso, não sei exatamente sobre cmd.exe implementar a parte de emulação de terminal em si mesmo. Eu não toquei em um compilador no Windows há algum tempo, mas se bem me lembro, é possível criar um "aplicativo de console" sem envolver cmd.exe . Consulte aqui e aqui .

    

Answer 3

gnome-terminal executará bash como um aplicativo padrão, mas xterm , gnome-terminal e familys são destinados a executar comandos arbitrários, não apenas shell, você pode executar por exemplo:

xterm -e /bin/bash
xterm -e /usr/local/bin/fish
xterm -e tail -f /var/log/messages
xterm -e man ls

no último caso, o xterm mostrará a minha página man, se eu sair, xterm irá sair.

no caso de / var / log / messages, eu posso usar as opções do xterm para definir fontes ou mudar de cor.

observe que gnome-terminal também usa a sintaxe -e para executar comandos.

    

Answer 4

O mundo do Windows é muito diferente do mundo do Unix. Uma das diferenças é que, no Windows, um executável possui dados especiais que informam ao sistema operacional que tipo de executável ele é; Para o propósito desta questão, existem tipos de executáveis em árvore:

• Executáveis que são executados no subsistema gráfico tradicional. Eles prometem criar suas próprias janelas, se necessário, e ler e responder a mensagens geradas pelo subsistema gráfico.

• Executáveis que são executados no subsistema do console. Eles exigem que o sistema operacional crie um tipo especial de janela para eles (um console ). O console assume as tarefas de recodificação de mensagens e fornece ao programa um ambiente mais simples.

• Executáveis que são executados no subsistema "Modern UI" pós-Windows 8. Esses programas são parecidos com os que são executados no subsistema gráfico, mas usam uma API diferente (e são tratados como uma classe separada de processos pelo SO).

cmd.exe não é o único programa executado em um console. Existem miríades de programas de console, incluindo portas de um grande número de utilitários GNU (ver, por exemplo, o projeto GnuWin32 ) e PowerShell , um shell baseado em console alternativo para o Windows 7 e mais recente, muito muito mais flexível e poderoso do que cmd.exe .

Quando um programa baseado em console é executado no console, você não interage diretamente com o programa, você interage com o subsistema do console que faz a mediação entre a entrada do usuário e o programa em execução; por exemplo, o subsistema do console traduz pressionamentos de tecla nos caracteres codificados esperados pelo programa baseado em console e usa um arquivo de fonte especificado para converter os caracteres gerados pelo programa nas belas pequenas figuras que o usuário vê.

    

Answer 5

Eu acho, porque no Linux você pode ter vários shell (bash ksh ....)

No Windows só tem 1 programa, o cmd. E agora a Microsoft precisa de 2 programas para adicionar mais funcionalidades (power shell)

No Linux só precisa alterar o shell para melhorar seus requisitos