RESUMO

RESUMO

A palavracomandorefere-se a dois conceitos diferentes no Linux:

  1. Um programa executável, comogrep(ou um shell embutido, comocd). Exemplo de uso: "Aqui estão os 10 principais comandos do Linux que você deve aprender."
  2. Uma string de texto completa enviada ao shell para execução, comogrep com /etc/hosts. Exemplo de uso: "Digite um comando Linux e pressione Enter."

Alguém tem alguma prática recomendada para evitar essa ambigüidade ao escrever prosa sobre comandos do Linux? Aqui estão algumas tentativas que já rejeitei:

  • Usando a palavraprogramaouexecutávelpara o significado # 1. É impreciso para shell integrados.
  • Usando a fraselinha de comandopara significado # 2. Isso é confuso porque “linha de comando” também é sinônimo de “shell”.
  • Usando a frasesequência de comandospara significado # 2. É impreciso porque #1 e #2 são strings.

Qualquer conselho apreciado.

Responder1

POSIXrefere-se às coisas que são como grepe cdcomo "Serviços de utilidade pública", ereservas "comando"para obter instruções. Usados ​​consistentemente, esses termos são inequívocos.


Para resolver seus casos por sua vez

  1. "Um programa executável, como grep (ou um shell integrado, como cd)"é umUtilitário:

    UtilitárioUm programa, excluindoutilitários integrados especiaisfornecido como parte da linguagem de comando do Shell, que pode ser chamado pelo nome de um shell para executar uma tarefa específica ou um conjunto relacionado de tarefas.

    Qual émais esclarecido com:

    O sistema pode implementar certos utilitários como funções shell ou utilitários integrados

    para ser explícito que isso incorpora utilitários comuns como trueos comumente encontrados como componentes internos do shell.

    Formalmente, "utilitários integrados especiais"são separados de utilitários não especificados com mais detalhes; são coisas como break, ., eval, set, e trap, que afetam o estado interno do shell, mas elesnãoinclude cd, que é um built-in regular. Fora das necessidades diferenciadas da especificação (certos comportamentos de atribuição de variáveis ​​são diferentes e não estão disponíveis com execvp), "utilitário" é suficiente para cobrir ambas as categorias no nível do usuário. Artigos de sintaxe de shell como ife whilenão são utilitários.

  2. "Uma string de texto completa enviada ao shell para execução, como grep com /etc/hosts"é umcomando:

    ComandoUma diretiva para o shell executar uma tarefa específica.

    Os comandos incluem comandos simples como grep com /etc/hostspipelines e comandos compostos como ifconstruções e comandos de agrupamento com ( ... ), mas a palavra "comando" nunca se refere a um utilitário em si. Dentro de um comando, umnome do comandopode aparecer que identifica um utilitário ou uma função: o nome do comando em grep com /etc/hostsis grep, referindo-se ao utilitário grep.


Os usos vernáculos de "comando" para significar uma utilidade ou função podem ser eliminados pelo contexto, mas o significado formal é apenas de uma instrução. Se for necessário evitar totalmente a ambiguidade,você pode usar consistentemente "utilitário" e "comando"para essas duas funções.

Você provavelmente não pode esperar que os próprios usuários façam essa distinção, portanto, os artigos dos "10 principais comandos do Linux" otimizados para mecanismos de pesquisa provavelmente estão fazendo a escolha certa para seus incentivos.

Responder2

RESUMO

O tipo de ambigüidade que você menciona perceber aqui é melhor remediado usando termos comoprograma, umarquivo executável, ou simplesmente umexecutávelpara aquele que tem/é um caminho, versuscomando shellou mesmolinha de comando quando você deseja fazer referência a tudo o que digita em seuinterpretador de comandos.


Contexto histórico

O índice das primeiras impressões deA linguagem de programação C("K&R", Prentice-Hall) continha apenas uma única menção da palavracomando, e não para essa palavra especificamente, mas paraargumentos de linha de comando. Este pequeno núcleo de significado fornece a semente crítica que germinou e se ramificou em todos os usos posteriores. Da página 111 de uma impressão de 1978:

5.11 Argumentos de linha de comando

Em ambientes que suportam C, existe uma maneira de passar argumentos ou parâmetros de linha de comando para um programa quando ele começa a ser executado.

Ou seja, a palavracomandoé usado exclusivamente em um contexto de shell (porque um shell, por definição, é uminterpretador de comandos), seja em uso interativo ou em programação com script. Os autores continuam com este exemplo:

A ilustração mais simples das declarações e usos necessários é o programa echo, que simplesmente repete seus argumentos de linha de comando em uma única linha, separados por espaços em branco. Isto é, se o comando

echo hello, world

é dado, a saída é

 hello, world

Observe como K&R falam sobre programas e linhas de comando lá. Em outras palavras, é o que o IEEEPOSIX1003.2é tudo sobre,nãoo quePOSIX1003.1é. Em termos gerais, Dot-1 cobre a programação C, enquanto Dot-2 cobre a programação shell.

E programação shell, não programação C, é o que você realmente está falando aqui. É por isso que a introduçãoSeção 1 do Manual do Programador Unixmenciona comandos, não chamadas de função:

NOME

intro — introdução aos comandos gerais (ferramentas e utilitários)

DESCRIÇÃO

As páginas de manual na seção 1 contêm a maioria dos comandos que compõem o ambiente do usuário BSD. Alguns dos comandos incluídos na seção 1 são editores de texto, interpretadores de shell de comando, ferramentas de pesquisa e classificação, comandos de manipulação de arquivos, comandos de status do sistema, comandos de cópia remota de arquivos, comandos de correio, compiladores e ferramentas de compilador, ferramentas de saída formatada e comandos de impressora de linha .

Todos os comandos definem um valor de status na saída que pode ser testado para verificar se o comando foi concluído normalmente. Os valores de saída e seus significados são explicados nos manuais individuais. Tradicionalmente, o valor 0 significa a conclusão bem-sucedida do comando.

Se você estivesse falando no jargão 1003.1, você poderia chamá-lo de argumento de string paraosistemafunção na biblioteca C. Isso porque não é um syscall em si, mas uma função de biblioteca que emprega vários syscalls subjacentes, um dos quais é execve. Esse syscall recebe um char *argumento constante como primeiro argumento, que é o caminho para o arquivo executável no sistema de arquivos.

Soluções publicadas

Uma solução publicada usa consistentemente as seguintes definições:

arquivo executável

Aarquivoque está especialmente marcado para informar osistema operacionalque não há problema em executar este arquivo como um programa. Geralmente abreviado para “executável”.

comando

Emconchaprogramação, a combinação sintática de um nome de programa e seus argumentos. Mais livremente, qualquer coisa que você digita em um shell (um interpretador de comandos) que o inicia fazendo alguma coisa. [...]

argumentos de linha de comando

Os valores que você fornece junto com o nome de um programa quando você informa um conchapara executar umcomando. [...]

nome do comando

O nome doprogramaatualmente em execução, conforme digitado nolinha de comando. [...]

        Extraído da quarta edição doProgramação Perl(O'Reilly), e aqui usado com a gentil permissão dos autores do livro. :) .

Se tiver sorte, você mesmo poderá encontrar tudo isso e muito mais, simplesmente digitando esta linha de comando simples em seu shell para que ele execute ohomemexecutável/programa para você:

man perlglossary

Mas se você não tiver essa sorte,você também pode encontrá-los aqui.

Comandos de shell

Este poderia ser um comando shell:

exec 2>errs.out

Observe que nada estava execlá; acabamos de reorganizar um descritor de arquivo.

Idem aqui:

exec 5<&0   # save old stdin
exec 0<&3   # read some_var
exec 0<&4   # read another_var
exec 0<&5   # restore it

Portanto, cada linha em um script é um “comando”, mesmo aqui (onde deixo como exercício para o leitor quantas execvesyscalls reais ele gera quando executado por completo):

#!/bin/sh
device=/dev/rmt8
dd_noise='^[0-9]+\+[0-9]+ records (in|out)$'
exec 3>&1
status=`((dd if=$device ibs=64k 2>&1 1>&3 3>&- 4>&-; echo $? >&4) | egrep -v "$dd_noise" 1>&2 3>&- 4>&-) 4>&1`
exit $status

Retirado da venerável JeremiadaProgramação Csh considerada prejudicial, novamente usado aqui com a gentil permissão, blá, blá, blá. :)

Responder3

Uma solução bastante simples (e a esquiva filosófica e linguística padrão) é distinguir entreUsandoa palavracomando, eMencionandoa palavracomando. Por exemplo, certas palavras realizam ações, mesmo no inglês comum, e seu uso é como elas o fazem. Se você disser "sim" nas circunstâncias adequadas, poderá se casar, por exemplo. Mas não se você estiver citando o que outra pessoa poderia dizer. Qualquer coisa citada é uma menção, não um uso.

Portanto, a primeira lista de comandos não são usos de comandos; são menções a comandos.

Os segundos exemplos, como o meu favorito

  • $ rev wordlist | sort | rev > speculum
    (que produz uma cópia em ordem alfabética reversa de wordlist)

realmente farão alguma coisa, então eles são definitivamente usos.

Responder4

eu considerarianão há necessidadecomo resposta, já que a ambigüidade descrita não causa nenhum dano de qualquer maneira.

Em todos os contextos que vi, quando a palavra "comando" se refere a um programa executável, é sempre algo que um usuário final digitaria em um shell para executá-lo. Nunca vi expressões como "o initcomando" ou "o ld-linux.socomando".

Quando "comando" se refere a um programa de linha de comando, na verdade sempre se refere à "família de comandos que começa com o referido programa". Por exemplo, quando você diz "o grepcomando", você está falando sobre todas as coisas que pode fazer com o grepprograma, que forma "uma família de comandos". Isso também vale para comandos parciais, como o ditado "o apt installcomando é para instalar pacotes"quando o comando completo apt installnormalmente não faz nada de útil.

informação relacionada