No curso, o Prof. Blau inicia com a história do Shell a fim de obter uma melhor contextualização. Decidi pesquisar a história por conta própria, pois achei fascinante a introdução dada pelo professor; todavia, havia lacunas inseridas por perguntas que surgiam durante a aula.

Comecei pela Wikipedia a respeito do Shell e, nas referências, encontrei o artigo The Origin of the Shell por Louis Pouzin.

The Origin of The Shell é um texto curto que trata da criação do “RUNCOM”, um “rascunho” do que viria a ser o Shell.

“I wrote ”RUNCOM”, a sort of shell driving the execution of command scripts, with argument substitution” - Louis Pouzin

Louis não se contentou com o “RUNCOM” — uma ferramenta para executar scripts de comandos com substituição de argumentos — e desejava desenvolver uma linguagem de programação baseada em comandos. Foi após o projeto de Christopher Strachey que Louis criou a base do que é o “Shell” do Multics. Ele escreveu estes papers:

Como não compreendi plenamente a proposta de Louis, decidi pesquisar o funcionamento do Compatible Time-Sharing System (CTSS), sistema utilizado por ele em 1964.

O primeiro conteúdo que encontrei foi muito esclarecedor: um vídeo de 1963, no qual o repórter John Fitch entrevista o Prof. Fernando J. Corbató, que demonstra e explica o funcionamento dos computadores e como operariam com o CTSS.

O Paradigma do Processamento em Lote (Batch Processing)

Os computadores necessitavam de uma entrada de dados e programas. Inicialmente, essa entrada ocorria via cartões perfurados. Contudo, devido ao alto custo do tempo de máquina e à rapidez do processamento em relação à leitura dos cartões, foram adotadas as fitas magnéticas como otimização. Isso aumentou a produtividade e diminuiu a ociosidade do processador.

Questionando o que seriam esses “programas”, entendi que eram códigos-objeto (binários), produtos da compilação de códigos-fonte escritos em FORTRAN ou Assembly, compilados no próprio IBM 7090 — o computador da época.

Utilizava-se um computador menor apenas para ler os cartões e gravar o conteúdo nas fitas magnéticas em um processo off-line. A fita, contendo o lote de vários usuários, era levada fisicamente ao computador principal.

O resultado não era impresso em tempo real. O computador principal gravava as saídas em outra fita magnética, que era levada de volta ao computador menor para a impressão em papel. O usuário só obtinha o resultado horas depois.

Ai que entra a necessidade de melhora, por exemplo, quando um usuário digitava um comando errado ou fornecia um dado incorreto: o trabalho era interrompido, o erro só seria percebido no dia seguinte, e a máquina prosseguia para o próximo job do lote.

A Solução: CTSS e o Supervisor

Não somente, mas principalmente pelo tempo, criou-se uma nova tecnologia, o “Compatible Time-Sharing System” (CTSS) e como ele resolvia esse problema?

Ele introduziu a figura do Supervisor, alterando a arquitetura de processamento:

  • O usuário não enviava mais dados via fita magnética; utilizava um Teletypewriter (TTY), equipamento semelhante a uma máquina de escrever. O que era digitado aparecia impresso como uma maquina de escrever, simutaneamente era lido pelo sistema e, ao responder, o computador movia as hastes de metal para imprimir o retorno no papel.
  • Vários usuários podiam utilizar o mesmo computador simultaneamente através de seus consoles. Esta tecnologia é chamada de Time-Sharing.
  • O Supervisor gerenciava o tempo de processamento: o processador dedicava, por exemplo, 200ms para cada usuário e mantinha as tarefas salvas em um disco magnético, realizando o Swapping (troca de contexto).

Evolução do Fluxo:

  • Antigo: Cartão Perfurado → Computador Satélite → Fita Magnética → Computador Principal → Impressão em lote.
  • CTSS: Comando → Teletipo → Computador principal → Teletipo → Retorno Impresso local.

O RUNCOM

Entendido o contexto :). Posso retornar ao RUNCOM, a solução para o problema que incomodava Louis Pouzin – Ufa!. O fluxo de trabalho manual ainda possuía etapas repetitivas:

  1. Chamar o editor de texto, digitar o código e salvar.
  2. Chamar o compilador e aguardar.
  3. Chamar o programa de cálculo.
  4. Responder manualmente às perguntas do programa (ex: “Raiz ou Hipotenusa?”).

Para testar 100 variações, o programador repetiria isso manualmente 100 vezes. Em 1964, Louis desejava otimizar o processo para “to go home in the evening while leaving behind long runcoms executing overnight.”

Ele chamava o programa RUNCOM e passava um script: RUNCOM testar. O RUNCOM enviava os comandos ao computador em sequência finita.

Comparativo:

  • Manual: O pesquisador digita FAP (Assembler), espera, digita LOAD, espera, insere os dados.
  • Com RUNCOM: Cria-se um script que compila, verifica erros e inicia a execução com dados predefinidos.

After having written dozens of commands for CTSS, I reached the stage where I felt that commands should be usable as building blocks for writing more commands, just like subroutine libraries. Hence, I wrote “RUNCOM”, (…) it was quite neat for boring and repetitive tasks such as renaming, moving, updating, compiling, etc. whole directories of files for system and application maintenance and monitoring. This idea of using commands somehow like a programming language was still in the back of my mind. – Louis Pouzin

Aqui inicia a base para o que é o Shell hoje:

  • O Shell como um Procedimento de Usuário (MDN-4): Louis Pouzin propôs que o interpretador de comandos não deveria ser uma função fixa e interna do Supervisor (núcleo), mas sim um programa comum de usuário. Isso permitiu que o sistema fosse extensível e que o Shell pudesse ser substituído ou melhorado sem a necessidade de recompilar todo o sistema operacional.
  • Encadeamento de Procedimentos (Chaining): A ideia de que comandos individuais poderiam servir como “blocos de construção” para tarefas maiores. O Shell atua como uma ferramenta global para chamar e encadear esses procedimentos, criando fluxos complexos a partir de comandos simples.
  • Processamento de Macro e Substituição (MDN-5): O RUNCOM evoluiu de um simples executor para um processador de macro-procedimentos. Isso introduziu a lógica de substituição de argumentos, permitindo que um único script fosse reutilizado com diferentes parâmetros, além de prever estruturas de controle como desvios condicionais e laços (loops).
  • Interface de Abstração: O Shell passou a ser a “casca” que protege o usuário da complexidade do hardware e do Supervisor, oferecendo uma linguagem de interface consistente e programável.

Embora Louis Pouzin tenha concebido a teoria e o fluxograma do sistema, ele retornou à França em 1965 antes de ver o código finalizado. A implementação prática do primeiro Shell do Multics foi realizada por Glenda Schroeder (do MIT) e Roy Feiertag (o engenheiro da General Electric citado por Pouzin). Foram eles que transformaram a visão de Pouzin no precursor direto de todos os interpretadores de comandos modernos, inclusive o Bourne Shell e o Bash que utilizamos hoje no GNU/Linux.