Qual é o padrão nos comandos do terminal?

Question

Apenas começando a mergulhar no terminal graças à divertida Raspberry Pi. Eu tenho uma coisa em particular que ainda me faz coçar a cabeça:

Estou percebendo os diferentes daemons / services / processes / applications / etc (qualquer outra coisa que estou deixando de fora?) que também são chamados de forma diferente.

Isso é o que eu quero dizer:

(programa, nome do arquivo)

nano mytextfile

(serviço, ação, programa)

service restart nginx

(ação, programa)

killall openvpn

Tem sido basicamente exercícios de memorização para mim neste momento e ainda não compreendi a sintaxe. É algo assim ?:

"service" when it's a service, as opposed to...? >
action for program if applicable >
name of program >
additional parameters

Alguém poderia, por favor, explicar brevemente a diferença entre essas e as diferentes maneiras de acessá-las?

    

Answer 1

O "padrão" é dado pela gramática do shell. Em casos simples, é um comando (ou melhor, um utilitário ), seguido por argumentos . Os argumentos podem ser opções , e as opções podem ter argumentos da opção . Após as opções, pode haver outros operandos .

Exemplo:

ls -l dir

ls é o comando, -l é uma opção (sem argumento de opção) e dir é um operando. Sabemos que dir não é um argumento de opção para a opção -l , pois lemos o manual ls no qual a seção de sinopses descreve a sequência de chamada do utilitário.

Exemplo:

git commit -p

git é o comando e, como não há opções imediatamente após o nome do comando, o restante é tratado como operandos. Cabe ao comando git interpretar isso. Você pode querer chamar o operando commit de um "subcomando" se desejar e -p uma "opção" para este subcomando.

Exemplo:

cc -o code.o -Wall code.c

Aqui, cc é o comando e as opções -o e -Wall são opções. A opção -o usa code.o como um argumento de opção. Dependendo do comando cc , a opção -Wall pode, de fato, ser analisada como -W all , ou seja, como uma opção com um argumento de opção (as opções de uma letra não exigem espaço antes de seus argumentos de opção). code.c é um operando como ocorre depois de todas as opções.

As palavras "argumento", "opção" e "argumento de opção" são aquelas usadas por Padrão POSIX . O padrão usa a palavra "utility" em vez de "command" como um comando pode ser simples, uma lista, composto, pipeline etc. Por exemplo, ls -l dir é um (simples) comando usando o utilitário ls e { head -n 20 | tail -n 5; } >file é um comando composto contendo um pipeline e dois comandos simples.

Indiscutivelmente, todas as invocações de utilitários são "ações". Dizer killall myprog significa "iniciar o utilitário killall com o operando myprog ". O efeito disso será que a utilidade, neste caso, envia um sinal para um processo.

Da mesma forma, service restart nginx é a ação de invocar o utilitário service com restart e nginx como os dois operandos. O efeito disso será que o serviço nginx seja reiniciado.

Da mesma forma, nano somedoc é a ação de invocar o editor nano , etc. etc.

    

Answer 2

Dos possíveis padrões listados, esse é o único que realmente existe:

name of program > additional parameters

Primeiro algumas definições de palavras:

• um programa ou uma aplicação: basicamente um arquivo que pode ser executado
• um processo: uma instância de um programa em execução no momento
• um daemon: um programa ou processo que está fazendo algo independentemente da sessão de login de qualquer usuário; geralmente algo que é ou pode ser iniciado automaticamente no momento da inicialização e é executado até que o sistema seja encerrado; coisas como servidor de protocolo de acesso remoto (por exemplo, sshd ), servidor web (Apache), gerenciador de conexões de rede ( NetworkManager , ModemManager ) ...
• um serviço: algo que geralmente é iniciado no momento da inicialização; pode ser um daemon ou apenas um script que configura algo e termina, e pode fazer as ações desmontadas correspondentes quando o sistema está sendo encerrado. Em alguns contextos, também pode se referir ao arranjo para fazer um programa iniciar na inicialização como um daemon.

service começou sua vida como um simples wrapper para scripts de inicialização / desligamento no estilo SysVinit. Se o SysVinit tradicional é usado como init system (o processo # 1, a "mãe de todos os processos") no Linux, esses scripts geralmente estão localizados no diretório /etc/init.d . Esses scripts possuem parâmetros padronizados: start para iniciar um serviço, stop para parar um ou status para consultar o estado de um serviço. Existem alguns outros.

Mas como escrever /etc/init.d/<service name> <action parameter> foi entediante, alguém criou um script de wrapper simples: service <name> <action parameter> originalmente significava apenas /etc/init.d/<name> <action parameter> .

Quando o SysVinit foi substituído por alternativas mais modernas ( systemd , upstart ou outros), as pessoas desejavam manter o familiar comando service e torná-lo um wrapper para o comando equivalente do sistema init . Quando systemd é usado, service <name> <action parameter> geralmente é apenas um wrapper para systemctl <action parameter> <name> . Observe a ordem alterada de parâmetros.

    

Answer 3

Primeiro no Unix, a filosofia é que tudo é um arquivo. Em todos os seus comandos, você está lidando apenas com arquivos em seu disco rígido: mytextfile , nginx ou openvpn são todos arquivos.

Agora, o que os arquivos representam e quais ações você pode ter sobre eles são meramente ditados por convenções. Às vezes, e vindo de algum outro sistema operacional, os arquivos têm extensões para ilustrar melhor o que fazem. Como um arquivo de texto que você pode editar estará com .txt no final, um programa será .sh ou .php ou .pl , etc. Mas existem apenas convenções (o unix bit x for execute é outra dica sobre o que é dados versus o que é executável)

O que você lista são ações ( nano , service restart , killall ) em diferentes objetos / arquivos ( mytextfile , nginx , openvpn ).

Dependendo da ação escolhida e dos objetos, os resultados serão diferentes. Você poderia também ter feito nano openvpn e editar ou criar um arquivo chamado openvpn onde você estiver (isso provavelmente seria inútil e perturbador, mas as ferramentas não proíbem isso).

Agora, quanto às suas ações específicas:

• nano é um editor de texto, para modificar o conteúdo de qualquer arquivo (claro, se for um arquivo binário - como alguns executáveis, mas não todos - seria a ferramenta errada para fazer qualquer coisa útil)
• service restart é uma ação com uma "subação" de reinicialização que usa a estrutura atual em seu sistema, lidando com iniciar / parar processos de longa duração, também chamados de daemons; note que é apenas um caso entre outros, poderia ter sido /etc/init.d/nginx restart em outro lugar ou systemctl restart nginx.service ; o fato de que restart existe como uma subação é inteiramente específico do comando service ; qualquer comando pode ter uma sintaxe diferente, com diferentes opções, argumentos, subações, etc. Ninguém consegue memorizar todos eles.
• e killall é um comando para examinar a lista de todos os processos em execução atuais e eliminar aqueles correspondentes ao nome dado (pouco de aviso: esse comando não faz as mesmas coisas em todos os sistemas Unix, portanto, leia seu manual no host que você está usando antes de usá-lo), então você poderia de fato fornecer qualquer nome e não necessariamente algo que existe como um arquivo no disco

Muitos de seus termos são sinônimos e vagamente definidos de qualquer maneira. Uma aplicação é qualquer coisa que possa rodar (ser executada), quando estiver rodando é um processo manipulado pelo kernel entre muitos outros processos. Aplicativos de longa vida normalmente não sob controle direto do usuário, como aplicativos de rede como um servidor da Web, eram freqüentemente chamados de daemons no passado e hoje são frequentemente chamados de serviços (ainda mais com systemctl veja a sintaxe de exemplo acima)

Você não deve memorizar qualquer tipo de coisa. Você aprenderá usando-os, como se você trabalhasse com nginx como servidor web, você precisará reiniciá-lo e em sua plataforma específica para isso é service restart e assim por diante.

    

Answer 4

Embora existam convenções padrão, como:

• IEEE
• GNU getopt

Não há nada que realmente impeça um desenvolvedor de violar as convenções por qualquer motivo e usar a sintaxe que quiserem. Então, depende da aplicação que você está usando no momento.

Geralmente, você encontrará o padrão GNU vinculado acima como muito comum e observará com o tempo que muitos comandos usam argumentos semelhantes para coisas semelhantes (por exemplo, -v para imprimir uma saída detalhada)

Não se preocupe em memorizar nada disso. Para os aplicativos que você usa regularmente, você acabará escolhendo a sintaxe e ela acabará se tornando uma segunda natureza. Para aplicativos com os quais você não está familiarizado, sempre há páginas man ou o --help flag.

Ter um conhecimento geral do que os comandos essenciais fazem e ser capaz de abrir e analisar rapidamente uma página de manual é infinitamente mais importante do que memorizar os sinalizadores para cada comando.