¿Qué hace "w" con urandom?

> strace w 2>&1 | grep urandom
read(4, "/usr/bin/grep\0urandom\0", 2047) = 22
>

¿Por qué "w" necesita urandom? ¿Cómo evitar esto?

ACTUALIZAR:

> strace w 2>&1 | awk '/urandom/'
read(4, "awk\0/urandom/\0", 2047)       = 14
>

Entonces, ¿es el filtrado lo que tiene que ver con el urandom?

> strace who 2>&1 | grep urandom
>

Entonces, ¿por qué no se ve afectado "quién"?

random w

— Marina Ala
fuente

No es lo wque necesita urandom. Es porquePiped commands run concurrently : unix.stackexchange.com/questions/37508/…

— Arkadiusz Drabczyk

@ArkadiuszDrabczyk Tiene sentido. No hay urandomacceso en el w código fuente.

— Rui F Ribeiro

Estás viendo el segundo comando en la tubería, tu grepy tu awk. No está wabriendo el /dev/urandomarchivo del dispositivo. Es similar aps -aux | grep grep

— Kusalananda

@RuiFRibeiro: correcto, también lo revisé para asegurarme. Creo que esta pregunta podría marcarse ahora como un duplicado.

— Arkadiusz Drabczyk

Puede hacer la pregunta sobre los unicornios: strace w 2>&1 | grep unicorns;-)

— Digital Trauma

Respuestas:

Como se explica en otras respuestas y comentarios, la razón de lo que observa es la forma en que Bashmaneja las tuberías. Para filtrar lo que realmente quiere en situaciones similares, puede intentar encerrar la primera letra del grepargumento de []esta manera:

$ 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 señaló correctamente R. en el comentario a continuación, de hecho strace, no ve el otro lado de la tubería. De manera similar a lo ps aux | grep grep que también se muestra grep grepen su salida wes caminar a través del /procdirectorio y encuentra el grepproceso allí.

— Arkadiusz Drabczyk
fuente

Feliz de ver a alguien más haciendo esto (aunque generalmente pongo entre paréntesis la última letra) con ps / strace, etc. La forma más fácil de evitar que encuentre su propia línea de comando.

— Monty Harder

Este truco parece ser cada vez más conocido. He oído que aparece en algunas preguntas frecuentes y se menciona muchas veces aquí en Stack Exchange .

— Scott

Esta respuesta, y los comentarios sobre la pregunta misma que dicen más o menos lo mismo, simplemente están equivocados. La otra respuesta (por ilkkachu) es correcta. straceno (y no puede, de ninguna manera fácil) rastrear los otros comandos en la tubería de shell. Más bien, westá buscando los comandos actuales que se ejecutan en su terminal (y otros terminales), y se ejecuta en el grep como parte de su trabajo.

— R .. GitHub DEJA DE AYUDAR A HIELO

Correcto, gracias, actualicé mi respuesta.

— Arkadiusz Drabczyk

Desde la página del manualw(1) :

w muestra información sobre los usuarios que se encuentran actualmente en la máquina y sus procesos

Para mostrar los procesos de los usuarios, pasa por todos los procesos que se ejecutan en la máquina. Intentemos esto:

$ strace -o w.trace w | grep whatever

Dentro de la traza encontramos líneas como estas (en un sistema Linux):

open("/proc/8286/cmdline", O_RDONLY)    = 4
read(4, "grep\0whatever\0", 2047)       = 14

Lo que muestra wexplícitamente pasar /procy mirar las líneas de comando de todos los procesos (y otras cosas, no se muestran). Encuentra el grepque corre paralelo a él y eso es lo que lo straceve hacer. La tubería no tiene nada que ver con eso, aparte de iniciar ambos procesos al mismo tiempo. En cierto modo, es similar a ps | grepver el grep en sí.

who y la mayoría de los otros comandos no necesitan la información sobre los procesos, y no van a buscar, por lo que no ve lo mismo al rastrearlos.

— ilkkachu
fuente