
> strace w 2>&1 | grep urandom
read(4, "/usr/bin/grep\0urandom\0", 2047) = 22
>
Por que "w" precisa de urandom? Como evitar isso?
ATUALIZAR:
> strace w 2>&1 | awk '/urandom/'
read(4, "awk\0/urandom/\0", 2047) = 14
>
então é a filtragem que tem algo a ver com urandom?
> strace who 2>&1 | grep urandom
>
Então por que “quem” não é afetado?
Responder1
cexibe informações sobre os usuários atualmente na máquina,e seus processos
Para exibir os processos dos usuários, ele percorre todos os processos em execução na máquina. Vamos tentar isso:
$ strace -o w.trace w | grep whatever
Dentro do trace encontramos linhas como estas (em um sistema Linux):
open("/proc/8286/cmdline", O_RDONLY) = 4
read(4, "grep\0whatever\0", 2047) = 14
O que mostra w
explicitamente a análise /proc
e observação das linhas de comando de todos os processos (e outras coisas, não mostradas). Ele encontra o grep
que corre paralelo a ele e é isso que strace
o vê fazer. O pipe não tem nada a ver com isso, a não ser iniciar os dois processos ao mesmo tempo. De certa forma, é semelhante a ps | grep
ver o próprio grep.
who
e a maioria dos outros comandos não precisa de informações sobre os processos e não procura, então você não vê o mesmo ao rastreá-los.
Responder2
Conforme explicado em outras respostas e comentários, o motivo do que você observa é a maneira como Bash
lida com os canos. Para filtrar o que você realmente deseja em situações semelhantes, você pode tentar incluir a primeira letra do grep
argumento []
assim:
$ strace w 2>&1 | grep random
read(4, "grep\0random\0", 2047) = 12
$ strace w 2>&1 | grep '[r]andom'
$ strace w 2>&1 | grep '[c]lose'
close(3) = 0
close(3) = 0
close(3) = 0
close(3) = 0
close(3) = 0
close(3) = 0
(...)
EDITAR:
Como corretamente observado porR.noComente abaixona verdade, strace
não vê o outro lado do cano. Da mesma forma ps aux | grep grep
que também mostra grep grep
em sua saída, w
está percorrendo
/proc
o diretório e encontra grep
o processo lá.