Qual é a relação entre o código de linha de comando e o código de idioma de nível superior?

Question

Estou aprendendo a usar o terminal no meu Ubuntu 14.04 e estou executando o código de linha de comando no meu shell (que me dizem que é o que está dentro do terminal) para instalar programas. Mas eu também posso iniciar meu servidor node.js no meu shell e, em seguida, posso executar o código javascript no terminal; ele controla os valores que armazeno em variáveis e posso criar funções e usá-las e assim por diante. No entanto, parece mudar de modo porque eu não estou mais em uma pasta específica do meu sistema operacional, então talvez eu não esteja mais no meu shell?

Então, comecei a pesquisar os comandos do shell:

O que são "comandos"?

De acordo com os comandos link podem ser de 4 tipos diferentes:

1. Um programa executável como todos esses arquivos em / usr / bin. Dentro desta categoria, os programas podem ser compilados binários, como programas escritos em C e C ++, ou programas escritos em linguagens de script, como o shell, Perl, Python, Ruby, etc.

2. Um comando embutido no próprio shell. O bash fornece vários comandos internamente chamados de shell builtins. O comando cd, por exemplo, é um shell embutido.

3. Uma função de shell . Estes são scripts de shell em miniatura incorporados ao ambiente.

4. Um alias . Comandos que você pode definir, construídos a partir de outros comandos.

Isso significa que estou sempre executando o código de nível superior que tenho em meus arquivos (por exemplo, arquivos x.php, x.js x.css x.html) com a ajuda do meu shell toda vez que eu inicio um programa? Ou isso significa apenas que eu posso usar a linha de comando para iniciar um programa que, em seguida, executar em outro lugar (se em algum outro lugar, então onde?)?

Como você pode entender a interação entre esses diferentes tipos de código / idiomas?

Por exemplo: você pode visualizar tudo como código colocado em uma linha de comando; linha após linha com alguns idiomas fazendo chamadas para outros idiomas que então retornam o controle para o chamador e assim por diante, ou que tipo de modelo mental é útil para entender o que está acontecendo?

    

Answer 1

Você está correto em dizer que, quando você abre um terminal, você está usando um shell. O principal trabalho de um shell é ajudá-lo a executar programas executáveis.

Então, o que é um executável? Digite ls e clique em retornar. Deve imprimir os arquivos no diretório atual. Agora, isso parece que o shell está executando algum tipo de comando interno chamado ls , certo? Errado! Na verdade, está criando um novo processo Linux que executa o programa executável /usr/bin/ls .

Então, por que escreveu a lista de arquivos no shell? Bem, o programa ls não sabe nada sobre o shell. Na verdade, não tem idéia de onde vai gravar. O que o programador fez foi fazer o programa escrever a lista para algo chamado saída padrão . O shell então usou um truque do Linux chamado pipe para fazer a lista imprimir no terminal.

Curiosamente, o shell também pode fazer esse padrão ir para outros lugares. Por exemplo, digitar ls > /tmp/ls.out não será impresso no terminal. Na verdade, está enviando a lista para um arquivo no diretório /tmp . Ainda mais interessante, digitar ls | less faz o shell iniciar o programa ls , assim como o programa less e canaliza o padrão de ls para o padrão em de less . Nenhum desses programas sabia nada sobre o shell nem, de fato, o shell sabia sobre como os programas funcionam: se o programa foi codificado da maneira padrão, tudo funcionará.

Agora, para o caso node.js . Novamente, o shell acabou de iniciar o programa node.js . Se você não fornecer argumentos, este programa tentará ler padrão em como less . Como você não canalizou nada para ele, o shell apenas conectou o teclado para que qualquer coisa que você digitasse sendo enviada para node . O shell também conectou o standard out ao terminal para que qualquer coisa que node escreveu fosse para o terminal como vimos ls do. O efeito líquido faz parecer que o shell agora entende JavaScript, mas não é assim. Ele realmente entende apenas a execução de programas e o redirecionamento de entrada / saída (pelo menos neste caso). É node fazendo o JS.

    

Answer 2

Eu nunca encontrei nada além de aprendizagem bottom-up útil para desenvolver um modelo mental de sistemas complexos.

Aprenda um pouco de linguagem assembly - não muito, apenas o suficiente para escrever uma sub-rotina de adição de números. Assista é fazer o seu trabalho, percorrendo-o no depurador. Descobrir que os ponteiros são nada mais que endereços de máquina, e uma string é realmente uma seqüência de células de memória terminada por uma célula com 0 (disclaimer: em algumas línguas).

Uma vez que você sabe disso, lembrá-lo quando você escreve em linguagens de alto nível é a melhor coisa que você pode fazer para obter uma imagem coerente de todo o sistema. Você entenderá imediatamente por que algumas coisas são mais lentas que outras e por que outras precisam de mais memória.

Depois de entender as linguagens de programação, dê uma olhada rápida na implementação de um shell de comando. Novamente, não muito tempo, apenas o suficiente para ver que é um programa como outros programas, apenas sua entrada e saída são outros comandos . Assista-o analisar uma linha de comando e, eventualmente, você 'obterá' porque os nomes de arquivos com espaços causam tantos problemas.

Opcionalmente, olhe dentro de um moderno daemon de inicialização do sistema e veja como ele usa scripts de shell, programas e chamadas de sistema para obter coisas (tente não ficar muito chocado com o quão frágil tudo parece).

Tudo isso leva tempo, mas acredito firmemente que você não pode ter uma impressão útil de um sistema tão complexo quanto um computador moderno sem investir um tempo considerável. É muito mais comum ir embora com um modelo mental meio equivocado e enganoso (pergunte a qualquer um que já tenha passado um dia trabalhando em suporte técnico). Também é improvável que você entenda tudo na pilha, mas tudo bem - ninguém entende a pilha inteira usada para computar qualquer coisa hoje. O cérebro humano é muito lento e valioso demais para tentar tal dublê.