Timing de ps canalizado para grep

7

Então, isso não é um problema como tal, apenas algo sobre o qual estou curioso. Estou usando o Linux Mint MATE que é ramificado do Debian. Se eu fizer:

ps afx  | grep abcdefg

Eu recebo:

16599 pts/3    S+     0:00  |   \_ grep --color=auto abcdefg

Então, está mostrando o processo para o grep. Mas, isso é após o ps no pipe: eu teria pensado que o acima faz o ps , obtém os resultados e passa-os para grep . Então, como o grep está realmente aparecendo nos resultados ps ? Isso não acontece depois? Acho que estou sentindo falta de algo fundamental sobre o que o pipe realmente faz.

    
por Max Williams 16.06.2015 / 12:42

3 respostas

4

Esta questão é uma duplicata e pertence a unix.stackexchange.com.

Em suma, ainda assim, o documento Idioma de Comando da Shell do OpenGroup é relativamente vago nos detalhes sobre " oleodutos ":

A pipeline is a sequence of one or more commands separated by the control operator '|'. The standard output of all but the last command shall be connected to the standard input of the next command.

The format for a pipeline is:

[!] command1 [ | command2 ...]

The standard output of command1 shall be connected to the standard input of command2. The standard input, standard output, or both of a command shall be considered to be assigned by the pipeline before any redirection specified by redirection operators that are part of the command (see Redirection).

If the pipeline is not in the background (see Asynchronous Lists), the shell shall wait for the last command specified in the pipeline to complete, and may also wait for all commands to complete.

Observe que, embora os dados fluam claramente de "da esquerda para a direita" no pipeline, não há garantia sobre o agendamento em si.

Veja também:

por 16.06.2015 / 13:46
2

O agendamento não importa muito. Se você considerar canalizar um trabalho de uma hora, o tubo permanecerá aberto continuamente desde o início do primeiro programa até a conclusão. O segundo programa é executado exatamente na mesma hora que o primeiro e ambos terminam ao mesmo tempo (em geral).

Em outras palavras, ps não obtém a saída e depois a envia para o grep - os dois são executados ao mesmo tempo, e a saída de um é inserida no segundo em tempo real . Ele não espera que o primeiro programa termine, colete uma hora de dados e envie tudo para o segundo de uma só vez.

Embora na prática exista algum nível de buffering (algumas centenas de caracteres) especialmente quando vários pipes estão envolvidos. Mas na maior parte do tempo, pense em ambos sendo executados ao mesmo tempo e falando diretamente um com o outro.

    
por 16.06.2015 / 15:57
0

Acho que há algum tempo envolvido aqui.

mkfifo /tmp/pipe
echo  >/tmp/pipe

(o processo do shell está suspenso)

Não importa o que comece primeiro, porque o escritor irá bloquear de qualquer maneira até que o leitor abra o seu final. E assim, porque praticamente qualquer programa sã do Unix iniciará o i / o antes de ver qualquer outra coisa, ps irá travar até que o processo grep seja estabelecido o suficiente pelo menos para que seja aberto na extremidade de leitura daquele tubo. / p>

cat </tmp/pipe &
echo >/tmp/pipe

(não pendure desta vez)

Essa ordem significa que você sempre vai acabar com grep .

Existem outras maneiras, no entanto.

Por exemplo, se você estiver procurando pelo argv0 de um processo em execução com um GNU ps , basta fazer:

ps -C argv0

Se você quiser usar grep , isso é totalmente factível, mas, dada uma pesquisa por argv0 novamente:

ps -eocomm= -opid=| grep ^argv0

... que excluirá os argumentos de cada comando.

E é claro que existe:

pgrep argv0
    
por 19.06.2015 / 19:09

Tags