Início / unix / Perguntas / 419256
Accepted
Sean
Asked: 2018-01-24 20:50:48 +0800 CST

Qual é o padrão nos comandos do terminal?

  • 772

Apenas começando a mergulhar no terminal graças ao divertido Raspberry Pi. Tenho uma coisa em particular que ainda me deixa coçando a cabeça:

Estou percebendo os diferentes daemons / serviços / processos / aplicativos / etc (algo mais que estou deixando de fora?) Que também são chamados de maneira diferente.

É mais ou menos isso que 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 compreendo 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 explicar brevemente a diferença entre estes e as diferentes formas de acessá-los?

terminal syntax

4 respostas

  1. Dos padrões potenciais que você listou, este é o único que realmente existe:

    nome do programa > parâmetros adicionais

    Primeiro, algumas definições de palavras:

    • um programa ou um aplicativo: basicamente um arquivo que pode ser executado
    • um processo: uma instância de um programa que está sendo executado 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 desligado; 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 normalmente é 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 de desativação correspondentes quando o sistema está sendo desligado. Em alguns contextos, também pode se referir ao arranjo para fazer um programa iniciar na inicialização como um daemon.

    servicecomeçou sua vida como um wrapper simples para scripts de inicialização/desligamento no estilo SysVinit. Se o SysVinit tradicional for usado como initsistema (o processo nº 1, a "mãe de todos os processos") no Linux, esses scripts geralmente estão localizados no /etc/init.ddiretório. Esses scripts têm parâmetros padronizados: startpara iniciar um serviço, stoppara interrompê-lo ou statuspara consultar o estado de um serviço. Existem alguns outros.

    Mas como escrever /etc/init.d/<service name> <action parameter>era tedioso, alguém criou um script 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, upstartou outros), as pessoas quiseram manter o servicecomando familiar e o transformaram em um wrapper para o comando equivalente em seu initsistema. Quando systemdé usado, service <name> <action parameter>geralmente é apenas um invólucro para arquivos systemctl <action parameter> <name>. Observe a ordem alterada dos parâmetros.

    • 3

  2. 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, nginxou openvpnsã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 eles fazem. Como um arquivo de texto que você pode editar estará .txtno final, um programa será .shou .phpou .pl, etc. Mas existem apenas convenções (o bit unix xpara executar é outra dica sobre o que é dado 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 que você escolher e dos objetos, os resultados serão diferentes. Você também poderia ter feito nano openvpne editaria, ou criaria, um arquivo chamado openvpnonde você está (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 que 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 para iniciar/parar processos de longa duração, também chamados de daemons; observe que é apenas um caso entre outros, poderia ter sido /etc/init.d/nginx restartem outro lugar ou systemctl restart nginx.service; o fato de restartexistir como uma subação é totalmente específico do servicecomando; qualquer comando pode ter sintaxe diferente, com diferentes opções, argumentos, subações, etc. Ninguém pode memorizá-los todos.
    • e killallé um comando para ver a lista de todos os processos em execução e eliminar os que correspondem ao nome fornecido (um aviso: este comando não faz as mesmas coisas em todos os sistemas Unix, portanto, certifique-se de ler o manual no host que você estão usando antes de usá-lo), então você pode fornecer qualquer nome e não necessariamente algo que exista como um arquivo no disco

    Muitos de seus termos são sinônimos e definidos vagamente de qualquer maneira. Um aplicativo é tudo o que pode ser executado (ser executado), quando está em execução é um processo tratado pelo kernel entre muitos outros processos. Aplicativos de vida longa normalmente não estão sob controle direto do usuário, como aplicativos de rede como um servidor da web, eram frequentemente chamados de daemons no passado e hoje são chamados de serviços (ainda mais com a systemctlsintaxe de exemplo acima)

    Você não deveria ter que memorizar nenhum tipo dessas coisas. Você aprenderá usando-os, como se você trabalha com nginxum servidor web, você precisará reiniciá-lo e em sua plataforma específica para isso service restarte assim por diante.

    • 1

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

    Não há nada realmente impedindo um desenvolvedor de quebrar a convenção por qualquer motivo e usar qualquer sintaxe que desejar. Então, na verdade, depende apenas do aplicativo que você está usando no momento.

    Geralmente, você descobrirá que o padrão GNU vinculado acima é muito comum e notará com o tempo que muitos comandos usam argumentos semelhantes para coisas semelhantes (por exemplo: -vpara imprimir uma saída detalhada)

    Não se preocupe em memorizar nada disso. Para os aplicativos que você usa regularmente, você eventualmente aprenderá a sintaxe e ela se tornará uma segunda natureza. Para aplicativos com os quais você não está familiarizado, sempre há páginas de manual ou o --helpsinalizador.

    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.

    • 1
  4. Best Answer

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

    Exemplo:

    ls -l dir

    lsé o comando, -lé uma opção (sem argumento de opção) e diré um operando. Sabemos que dirnão é um argumento de opção para a -lopção, pois lemos o lsmanual em que a seção de sinopse 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 gitcomando interpretar isso. Você pode querer chamar o commitoperando de "subcomando" se desejar, e -puma "opção" para este subcomando.

    Exemplo:

    cc -o code.o -Wall code.c

    Aqui, ccé o comando e ambos -oe -Wallsão opções. A -oopção recebe code.ocomo um argumento de opção. Dependendo do cccomando, a -Wallopção pode de fato ser analisada como -W all, ou seja, como uma opção com um argumento de opção (opções de uma letra não requerem um espaço antes de seus argumentos de opção). code.cé um operando, pois ocorre após todas as opções.

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

    Indiscutivelmente, todas as invocações de utilidade são "ações". Dizer killall myprogsignifica "iniciar o utilitário killallcom 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 serviceutilitário com restarte nginxcomo os dois operandos. O efeito disso será que o nginxserviço é reiniciado.

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

    • 1

relate perguntas