staging.inyokaproject.org

UlfZibis schrieb:

kB schrieb: […] Wenn meine Vermutung stimmt, wird die Ausgabe so unterdrückt:

lightdm --show-config 2>/dev/null 

Bei mir kommt da folgendes:

ich@T500:~$ lightdm --show-config
[…]

Ich hoffe, dass ist Dir nützlich.

Nein, das ist nicht nützlich, weil Du ja überhaupt nicht auf meine Frage eingehst und lediglich mit unnützem Müll hier das Forum vollspamst.

kB schrieb:

Nein, das ist nicht nützlich, weil Du ja überhaupt nicht auf meine Frage eingehst und lediglich mit unnützem Müll hier das Forum vollspamst.

Sach' mal, geht's noch ???

Zum Thema. Was wolltest Du denn wissen?

EDIT: Ich habe Dir – wie ich meine wunschgemäß – bestätigt, dass lightdm --show-config 2>/dev/null die Ausgabe unterdrückt. Das eigentliche Thema war aber doch, wie die Ausgabe mit grep filtern. Und so habe ich dann auch noch bestätigt, dass dass Unterdrücken dafür nicht hilfreich ist.

UlfZibis schrieb:

[...] EDIT: Ich habe Dir – wie ich meine wunschgemäß – bestätigt, dass lightdm --show-config 2>/dev/null die Ausgabe unterdrückt. [...]

Das ist so an sich nicht verwunderlich.

karzer schrieb:

Das ist so an sich nicht verwunderlich.

Also lautet der gesuchte Befehl:

lightdm --show-config 2>&1 | grep unity 

UlfZibis schrieb:

[...] Also lautet der gesuchte Befehl:

lightdm --show-config 2>&1 | grep unity 

Wenn ich das richtig verstehe, möchte kB prüfen, ob bzw. was LightDM auf den stderr schreibt. Dies dürfte mittels

lightdm --show-config 2> lightdm.stderr; cat lightdm.stderr

auf einem System mit LightDM herauszufinden sein.

UlfZibis schrieb:

[…] Ich habe Dir – wie ich meine wunschgemäß – bestätigt, dass lightdm --show-config 2>/dev/null die Ausgabe unterdrückt.

Wie man im Diskussionsverlauf nachlesen kann, hast Du das genau nicht gemacht.

Das eigentliche Thema war aber doch, wie die Ausgabe mit grep filtern.

Nein. Ich habe einen Test vorgeschlagen zur Überprüfung meiner Vermutung, warum die übliche Filterung mit grep in diesem Fall nicht funktioniert. Diesen Test hast Du nicht realisiert.

Und so habe ich dann auch noch bestätigt, dass dass Unterdrücken dafür nicht hilfreich ist.

Auch das hast Du mit Deiner Antwort nicht getan. Um wenn Du es getan hättest, wäre es geistiger Dünnschiss: Natürlich kann man eine bereits unterdrückte Ausgabe niemals filtern. Wo nichts mehr ist, kann man auch nichts mehr wegnehmen.

karzer schrieb:

[…] Wenn ich das richtig verstehe, möchte kB prüfen, ob bzw. was LightDM auf den stderr schreibt.

Nur das.

Dies dürfte mittels

lightdm --show-config 2> lightdm.stderr; cat lightdm.stderr

auf einem System mit LightDM herauszufinden sein.

Ja. Oder auch einfacher, da man schon weiß, das

lightdm --show-config 

eine Ausgabe erzeugt, indem man (wie von mir vorgeschlagen) prüft, ob

lightdm --show-config 2>/dev/null 

keine Ausgabe erzeugt.

Dann weiß man nämlich aufgrund allgemeiner logischer Gesetze:

• ligtdm schreibt nichts auf stdout, sondern alles auf stderr. Was erklärt, warum grep per Pipe hier nicht filtert. Außer man bedient die Umleitungen zweckmäßig.

kB schrieb:

[...] Ja. Oder auch einfacher, da man schon weiß, das

lightdm --show-config 

eine Ausgabe erzeugt, indem man (wie von mir vorgeschlagen) prüft, ob

lightdm --show-config 2>/dev/null 

keine Ausgabe erzeugt.

Dann weiß man nämlich aufgrund allgemeiner logischer Gesetze:

• ligtdm schreibt nichts auf stdout, sondern alles auf stderr. Was erklärt, warum grep per Pipe hier nicht filtert. Außer man bedient die Umleitungen zweckmäßig.

Hm, aber hatte genau das nicht UlfZibis ermittelt?

UlfZibis schrieb:

[...] Bei mir kommt da folgendes:

ich@T500:~$ lightdm --show-config
   [Seat:*]
H  allow-guest=true
C  greeter-wrapper=/usr/lib/lightdm/lightdm-greeter-session
D  guest-wrapper=/usr/lib/lightdm/lightdm-guest-session
E  greeter-session=unity-greeter
F  user-session=unity
G  xserver-command=X -core

   [LightDM]
B  backup-logs=false

Sources:
A  /usr/share/lightdm/lightdm.conf.d/50-disable-guest.conf
B  /usr/share/lightdm/lightdm.conf.d/50-disable-log-backup.conf
C  /usr/share/lightdm/lightdm.conf.d/50-greeter-wrapper.conf
D  /usr/share/lightdm/lightdm.conf.d/50-guest-wrapper.conf
E  /usr/share/lightdm/lightdm.conf.d/50-unity-greeter.conf
F  /usr/share/lightdm/lightdm.conf.d/50-unity.conf
G  /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf
H  /etc/lightdm/lightdm.conf.d/50-enable-guest-session.conf
[...]
ich@T500:~$ lightdm --show-config 2>/dev/null 
ich@T500:~$ [...]

Ich hoffe, dass ist Dir nützlich.

Da die Annahme von kB sich bestätigt hat, dass der Befehl auf die Standardfehlerausgabe schreibt, müsste das Filtern der Ausgabe von LightDM mit grep folgendermaßen funktionieren:

lightdm --show-config 2>&1 > /dev/null | grep "unity" 

kB schrieb:

Auch das hast Du mit Deiner Antwort nicht getan. Um wenn Du es getan hättest, wäre es geistiger Dünnschiss: Natürlich kann man eine bereits unterdrückte Ausgabe niemals filtern. Wo nichts mehr ist, kann man auch nichts mehr wegnehmen.

Ja was denn nun? Entweder das eine, oder das andere?
Dann entscheide ich mich für den geistigen Dünnschiss. War tatsächlich nur ein "try and error"-Ansatz, ohne weiter darüber nachgedacht zu haben.

karzer schrieb:

Hm, aber hatte genau das nicht UlfZibis ermittelt?

Danke, dass wenigstens Du es gelesen / verstanden hast.

karzer schrieb:

Da die Annahme von kB sich bestätigt hat, dass der Befehl auf die Standardfehlerausgabe schreibt, müsste das Filtern der Ausgabe von LightDM mit grep folgendermaßen funktionieren:

lightdm --show-config 2>&1 > /dev/null | grep "unity" 

Schrieb ich ja schon, und > /dev/null ist doch wohl überflüssig. Wo nichts ist, muss auch nichts nach Null umgeleitet werden.

karzer schrieb:

kB schrieb:

[...] Ja. Oder auch einfacher, da man schon weiß, das

lightdm --show-config 

eine Ausgabe erzeugt, indem man (wie von mir vorgeschlagen) prüft, ob

lightdm --show-config 2>/dev/null 

keine Ausgabe erzeugt.

Dann weiß man nämlich aufgrund allgemeiner logischer Gesetze:

• ligtdm schreibt nichts auf stdout, sondern alles auf stderr. Was erklärt, warum grep per Pipe hier nicht filtert. Außer man bedient die Umleitungen zweckmäßig.

Hm, aber hatte genau das nicht UlfZibis ermittelt?

Nein. Er hat nicht den von mir vorgeschlagenen Befehl ausgeführt, zu dem ich keine Ausgabe erwartet, sondern einen anderen (den Du im folgenden ja auch richtig zitierst), der eine Ausgabe erzeugt, was vorher schon bekannt war und dessen konkrete Ausgabe auch völlig irrelevant ist:

UlfZibis schrieb:

[...] Bei mir kommt da folgendes:

ich@T500:~$ lightdm --show-config
   [Seat:*]
H  allow-guest=true
[…]

kB schrieb:

[...]

Hm, aber hatte genau das nicht UlfZibis ermittelt?

Nein. Er hat nicht den von mir vorgeschlagenen Befehl ausgeführt, zu dem ich keine Ausgabe erwartet, sondern einen anderen (den Du im folgenden ja auch richtig zitierst), der eine Ausgabe erzeugt, was vorher schon bekannt war und dessen konkrete Ausgabe auch völlig irrelevant ist:

UlfZibis schrieb:

[...] Bei mir kommt da folgendes:

ich@T500:~$ lightdm --show-config
   [Seat:*]
H  allow-guest=true
[…]

Aber das ist doch nicht die ganze Ausgabe? Den Befehl lightdm --show-config 2>/dev/null, den Du zum Test vorgeschlagen hattest, hatte UlfZibis hier ausgeführt.

Hat Dich vielleicht der lange Codeblock irritiert? Ich gebe zu, das ist unübersichtlich, aber da wurde eine ganze Reihe von Befehlen getestet, nicht nur der von Dir Markierte.

kB schrieb:

Nein. Er hat nicht den von mir vorgeschlagenen Befehl ausgeführt, ...

Doch, hat er. karzer kann's bezeugen.

Und wenn ich zeigen will, dass 2>/dev/null "etwas" unterdrückt, dann muss ich auch den Kontrollversuch machen, der zeigt, dass überhaupt "etwas" da ist zum Unterdrücken. Alles andere wäre "unwissenschaftlich".

UlfZibis schrieb:

kB schrieb:

Nein. Er hat nicht den von mir vorgeschlagenen Befehl ausgeführt, ...

Doch […]

Ok. Ich habe es jetzt in Deiner unübersichtlichen Ausgabe gefunden.

Es wäre besser gewesen, Du hättest Dich auf den schlichten Test wie z.B. „Der Befehl "lightdm --show-config 2>/dev/null" erzeugt bei mir keine Ausgabe.“ beschränkt und alles nicht relevante weg gelassen, dann hätte es diesen Disput nicht gegeben. Sorry.

Und wenn ich zeigen will, dass 2>/dev/null "etwas" unterdrückt, dann muss ich auch den Kontrollversuch machen, der zeigt, dass überhaupt "etwas" da ist zum Unterdrücken. Alles andere wäre "unwissenschaftlich".

Da hast Du grundsätzlich Recht, aber in diesem Fall kennen wir ja den Sachverhalt schon aus dem Artikel.

kB schrieb:

Nein, das ist nicht nützlich, weil Du ja überhaupt nicht auf meine Frage eingehst und lediglich mit unnützem Müll hier das Forum vollspamst.

Da abfällige Unterstellungen hier sehr beliebt sind und selbst nach Erkennen des Irrtums Belehrungen favorisiert werden, versuche ich es dann auch mal damit:
Also statt mit solchen Polter-Behauptungen hättest Du es vielleicht mit freundlichem Fragen versuchen können, dann wärest Du sicher schneller zum Ziel gekommen.

Und die 2. Chance hast Du dann auch noch in den Wind geschlagen: UlfZibis schrieb:

Zum Thema. Was wolltest Du denn wissen?

Für den 2. überflüssigen Teil meiner langen Ausgabe hatte ich mich ja schon entschuldigt.

Aber Danke, dass auch Du Dich entschuldigt hast.

... aber in diesem Fall kennen wir ja den Sachverhalt schon aus dem Artikel.

Da ich ihn aber nicht kannte, habe ich ihn überprüft und protokolliert.