
A palavracomandorefere-se a dois conceitos diferentes no Linux:
- 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."
- 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 grep
e cd
como "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
"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
true
os 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
, etrap
, que afetam o estado interno do shell, mas elesnãoincludecd
, 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 comexecvp
), "utilitário" é suficiente para cobrir ambas as categorias no nível do usuário. Artigos de sintaxe de shell comoif
ewhile
não são utilitários."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/hosts
pipelines e comandos compostos comoif
construçõ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 emgrep com /etc/hosts
isgrep
, 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 comandoecho 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 exec
lá; 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 execve
syscalls 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 dewordlist
)
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 init
comando" ou "o ld-linux.so
comando".
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 grep
comando", você está falando sobre todas as coisas que pode fazer com o grep
programa, que forma "uma família de comandos". Isso também vale para comandos parciais, como o ditado "o apt install
comando é para instalar pacotes"quando o comando completo apt install
normalmente não faz nada de útil.