Was macht "w" mit Urandom?

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

Warum braucht "w" urandom? Wie vermeide ich das?

AKTUALISIEREN:

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

Also ist es die Filterung, die etwas mit Urandom zu tun hat?

> strace who 2>&1 | grep urandom
>

Warum ist dann nicht "wer" betroffen?

random w

— Marina Ala
quelle

Es ist nicht wwas braucht urandom. Es ist weil Piped commands run concurrently: unix.stackexchange.com/questions/37508/…

— Arkadiusz Drabczyk

@ArkadiuszDrabczyk Sinnvoll. Es gibt keinen urandomZugriff im w Quellcode.

— Rui F Ribeiro

Sie sehen den zweiten Befehl in der Pipeline, Ihren grepund Ihren awk. Die Gerätedatei wird nicht wgeöffnet /dev/urandom. Es ist ähnlich wieps -aux | grep grep

— Kusalananda

@RuiFRibeiro: Richtig, ich habe es auch überprüft, um sicherzugehen. Ich denke, diese Frage könnte jetzt als Duplikat markiert werden.

— Arkadiusz Drabczyk

Sie können die Frage über Einhörner stellen: strace w 2>&1 | grep unicorns;-)

— Digital Trauma

Antworten:

Wie in anderen Antworten und Kommentaren erläutert, ist der Grund für Ihre Beobachtung der Umgang Bashmit Rohren. Um zu filtern, was Sie in ähnlichen Situationen wirklich wollen, können Sie versuchen, den ersten Buchstaben des grepArguments []wie folgt einzuschließen :

$ 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
(...)

BEARBEITEN:

Wie korrekt bemerkt R. im Kommentar unten in der Tatstrace sieht die andere Seite des Rohrs nicht. Ähnlich wie es ps aux | grep grep auch grep grepin seiner Ausgabe zu sehen wist, geht es durch das /procVerzeichnis und findet dort den grepProzess.

— Arkadiusz Drabczyk
quelle

Ich bin froh zu sehen, dass jemand anderes dies tut (obwohl ich normalerweise stattdessen den letzten Buchstaben in Klammern setze), mit ps / strace usw. Der einfachste Weg, um zu verhindern, dass er seine eigene Befehlszeile findet.

— Monty Harder

Dieser Trick scheint weithin bekannt zu werden. Ich habe gehört, dass es in einigen FAQs aufgeführt ist und hier auf Stack Exchange oft erwähnt wird .

— Scott

Diese Antwort und die Kommentare zu der Frage selbst, die ungefähr dasselbe sagen, sind einfach falsch. Die andere Antwort (von ilkkachu) ist richtig. straceverfolgt die anderen Befehle in der Shell-Pipeline nicht (und kann sie auch nicht auf einfache Weise verfolgen). Es wird vielmehr wnach den aktuellen Befehlen gesucht, die auf Ihrem Terminal (und anderen Terminals) ausgeführt werden, und im Rahmen seiner Arbeit über den Grep ausgeführt.

— R .. GitHub STOP HELPING ICE

Richtig, danke, ich habe meine Antwort aktualisiert.

— Arkadiusz Drabczyk

Aus der Manpagew(1) :

w zeigt Informationen zu den aktuell auf dem Computer befindlichen Benutzern und ihren Prozessen an

Um die Prozesse der Benutzer anzuzeigen, werden alle auf dem Computer ausgeführten Prozesse durchlaufen. Lass uns das versuchen:

$ strace -o w.trace w | grep whatever

In der Spur finden wir Zeilen wie diese (auf einem Linux-System):

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

Dies zeigt, wie wexplizit /procdie Befehlszeilen aller Prozesse (und anderer Dinge, die nicht gezeigt werden) durchlaufen und betrachtet werden. Es findet das grep, was parallel dazu läuft und das ist wasstrace sieht es. Die Pipe hat nichts damit zu tun, außer beide Prozesse gleichzeitig zu starten. In gewisser Weise ähnelt es ps | grepdem Grep selbst.

who und die meisten anderen Befehle benötigen keine Informationen zu den Prozessen und suchen nicht, sodass Sie beim Nachverfolgen nicht dasselbe sehen.

— ilkkachu
quelle