Softpicks.Net Deutsch

[schmedi]

> Also Beispiel:
>
> programm 2>&1 |grep "suchwort" || aktion
>


Das Beispiel ist nat=FCrlich totaler Quatsch.
Statt dem || muss ein && hin.=20
Geht das =FCberhaupt?

Bitte helfen!

.

[Hauke Laging]

schmedi schrieb am Mittwoch 13 September 2006 13:17:

> da mir das letzte Mal hier so schnell geholfen wurde

Wenn mal 'ne frau hier auftaucht... ;-)


> Ich möchte die Standard Fehler Ausgabe eines Programmes auf ein
> bestimmtes Kommando hin überwachen und wenn dort ein bestimmtes
> Wort auftaucht, soll etwas ausgeführt werden.
> Gleichzeitig sollen aber sowohl Standard Fehler als auch Standard
> Ausgabe immer auf der Konsole ausgegeben werden.

echo ... | tee /dev/tty | grep ...


CU

Hauke
--
http://www.hauke-laging.de/ideen/
http://www.hauke-laging.de/software/
http://zeitstempel-signatur.hauke-laging.de/
Wie können 59.054.087 Leute nur so dumm sein?
.

[Hauke Laging]

schmedi schrieb am Mittwoch 13 September 2006 13:59:
^^^^^^^
Aber daran kannst Du noch arbeiten.

> Also wie muss das aussehen?
>
> <wpa_supplicant aufruf> 2>&1 | tee >/dev/tty | grep "fehler" ||
> wpa_cli terminate ... und wie weiter?

Nee, mit || is da nix, denn dafür muss sich die Pipe erst mal
beenden, was sie aber nicht tut.

.... | grep | read line

Das war mein Gedanke. Man braucht irgendwas, das sich beendet, sobald
grep war durchreicht, und so per SIGPIPE die ganze Sache erledigt.

Das klappt aber erst beim nächsten Schreibversuch. Wenn vor dem
Fehler mindestens eine Zeile ausgegeben wird, kann man sich so
behelfen:

.... | grep --before-context=1 --line-buffered | read line

Das klappt aber nur dann brauchbar, wenn der erste Prozess ständig
schreibt, also nach der Fehlermeldung noch irgendwas kommt.

Ansonsten müsste man am Ende der Pipe nach dem read line den ersten
Prozess killen. Also z.B. die eigene process group bestimmen und
dann mit kill -HUP -$pgid in die Menge schießen.

> das wird ja dann so ne art rekursion, gibt es denn kein goto in der
> bash?

> Und das mit dem tee >/dev/tty schreibt immer auf die aktuelle
> Konsole?

Nimm mal das ">" weg, tee will eine "Datei", keine Umleitung. So
klemmst Du den Rest der Pipe ab.

Das ganze kommt dann in eine Endlosschleife:
while true
do
wpa_supplicant aufruf
: aufräumen
done


CU

Hauke
--
http://www.hauke-laging.de/ideen/
http://www.hauke-laging.de/software/
http://zeitstempel-signatur.hauke-laging.de/
Wie können 59.054.087 Leute nur so dumm sein?
.

[Dirk Clemens]

Hauke Laging wrote:
> schmedi schrieb am Mittwoch 13 September 2006 13:59:
> ^^^^^^^
> Aber daran kannst Du noch arbeiten.
>
>> Also wie muss das aussehen?
>>
>> <wpa_supplicant aufruf> 2>&1 | tee >/dev/tty | grep "fehler" ||
>> wpa_cli terminate ... und wie weiter?
>
> Nee, mit || is da nix, denn dafür muss sich die Pipe erst mal
> beenden, was sie aber nicht tut.
>

Könnte da nicht die grep Option -l helfen, so dass grep nur
die erste Existenz der Suchbefgriffes überprüft und danach
sofort terminiert.

Dirk
.

[Helmut Schellong]

schmedi wrote:
>> Wenn mal 'ne frau hier auftaucht...
>
> hihi, na dann kann ich euch ja gleich mein gesamtes Problem übergeben,
> bei mir klappt heute gar nichts.
>
> Also es geht um folgendes:
>
> Ich will die Fehlerausgaben vom wpa_supplicant überwachen und wenn
> dort ein bestimmtes Wort auftaucht, dann soll der supplicant beendet
> und wieder neu gestartet werden, aber halt wieder so, dass die
> Fehlerausgaben überwacht werden und gegebenenfalls neu gestartet
> werden kann.
>
> Ja ich weiss, das ganze hört sich nach Murks an, ist es vermutlich
> auch. Aber ich würde es gern probieren.
>
> Also wie muss das aussehen?
>
> <wpa_supplicant aufruf> 2>&1 | tee >/dev/tty | grep "fehler" || wpa_cli
> terminate ... und wie weiter?
>
> das wird ja dann so ne art rekursion, gibt es denn kein goto in der
> bash?


wpa start

while sleep 1
do
[ -s /tmp/wpa_err ] || continue
grep '\<fehler\>' /tmp/wpa_err || { :>/tmp/wpa_err; continue; }
wpa stop
sleep 3
wpa start
done


Voraussetzungen:
wpa start ist ein Skript, das im Hintergrund laufen läßt
und Fehlertexte in /tmp/wpa_err landen läßt.


--
Mit freundlichen Grüßen
Helmut Schellong var [at] schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
.

[Hauke Laging]

Helmut Schellong schrieb am Donnerstag 14 September 2006 00:54:

> grep '\<fehler\>' /tmp/wpa_err || { :>/tmp/wpa_err; continue; }

race condition, race condition...
--
http://www.hauke-laging.de/ideen/
http://www.hauke-laging.de/software/
http://zeitstempel-signatur.hauke-laging.de/
Wie können 59.054.087 Leute nur so dumm sein?
.

[Helmut Schellong]

Hauke Laging wrote:
> Helmut Schellong schrieb am Donnerstag 14 September 2006 00:54:
>
>> grep '\<fehler\>' /tmp/wpa_err || { :>/tmp/wpa_err; continue; }
>
> race condition, race condition...

Ja, ist bewußt so einfach belassen (falls truncate von wpa_err gemeint ist,
zusammenhanglich mit einem anderen asynchronen Prozeß, der hier nicht sichtbar ist).

Ich habe ein bsh-Skript vermieden, wo sowas einfacher
professioneller implementierbar ist.

Eine erste Verbesserung wäre, eine bestimmte Dateigröße auflaufen zu lassen.
Aber dafür würde ich bsh-fstat verwenden ... also hab' ich's gelassen.


--
Mit freundlichen Grüßen
Helmut Schellong var [at] schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
.

[Hauke Laging]

Helmut Schellong schrieb am Donnerstag 14 September 2006 02:00:

>>> grep '\<fehler\>' /tmp/wpa_err || { :>/tmp/wpa_err; continue;
>>> }
>>
>> race condition, race condition...
>
> Ja, ist bewußt so einfach belassen (falls truncate von wpa_err
> gemeint ist, zusammenhanglich mit einem anderen asynchronen Prozeß,
> der hier nicht sichtbar ist).

Nein, das ist nicht gemeint, das wäre ja auch abwegig (wenngleich
möglich). Gemeint ist, dass wpa zwischen dem Erreichen des
Dateiendes durch grep und dem Löschen der Datei durch den
Folgeprozess die fragliche Ausgabe produziert haben kann, die dann
einfach mal den Bach runtergeht.


CU

Hauke
--
http://www.hauke-laging.de/ideen/
http://www.hauke-laging.de/software/
http://zeitstempel-signatur.hauke-laging.de/
Wie können 59.054.087 Leute nur so dumm sein?
.

[Helmut Schellong]

Hauke Laging wrote:
> Helmut Schellong schrieb am Donnerstag 14 September 2006 02:00:
>
>>>> grep '\<fehler\>' /tmp/wpa_err || { :>/tmp/wpa_err; continue;
>>>> }
>>> race condition, race condition...
>> Ja, ist bewußt so einfach belassen (falls truncate von wpa_err
>> gemeint ist, zusammenhanglich mit einem anderen asynchronen Prozeß,
>> der hier nicht sichtbar ist).
>
> Nein, das ist nicht gemeint, das wäre ja auch abwegig (wenngleich
> möglich). Gemeint ist, dass wpa zwischen dem Erreichen des
> Dateiendes durch grep und dem Löschen der Datei durch den
> Folgeprozess die fragliche Ausgabe produziert haben kann, die dann
> einfach mal den Bach runtergeht.

Genau das habe ich doch geschrieben: "truncate von wpa_err", s.o.

----------------

Wenn ich etwas programmiere, durchdenke ich es stets gründlich:

o Im Moment existiert offenbar gar keine Überwachung ...
o Wie lange dauert "|| { :>....."? Sagen wir mal 1 us.
Damit sind wir bei 1:1000000 Wahrscheinlichkeit.
o Dies auch nur, wenn wpa 1-mal pro Sekunde was schreibt.
o Wenn wpa alle 100s was schreibt, sind wir bei 1:1000000*100.
o Wenn wpa jedes 100ste Mal das Suchwort schreibt, sind wir
bei 1:1000000*100*100 = 1:10^10

In der Praxis kann man oft mit solchen Wahrscheinlichkeiten leben.
10^10 Sekunden ist ein immens langer Zeitraum - über 300 Jahre.


--
Mit freundlichen Grüßen
Helmut Schellong var [at] schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
.

[Hauke Laging]

Helmut Schellong schrieb am Donnerstag 14 September 2006 03:41:

> Hauke Laging wrote:
>> Helmut Schellong schrieb am Donnerstag 14 September 2006 02:00:
>>
>>>>> grep '\<fehler\>' /tmp/wpa_err || { :>/tmp/wpa_err;
>>>>> continue; }
>>>> race condition, race condition...
>>> Ja, ist bewußt so einfach belassen (falls truncate von wpa_err
>>> gemeint ist, zusammenhanglich mit einem anderen asynchronen
>>> Prozeß, der hier nicht sichtbar ist).
>>
>> Nein, das ist nicht gemeint, das wäre ja auch abwegig (wenngleich
>> möglich). Gemeint ist, dass wpa zwischen dem Erreichen des
>> Dateiendes durch grep und dem Löschen der Datei durch den
>> Folgeprozess die fragliche Ausgabe produziert haben kann, die dann
>> einfach mal den Bach runtergeht.
>
> Genau das habe ich doch geschrieben: "truncate von wpa_err", s.o.

Nein, Du hast geschrieben: "zusammenhanglich mit einem anderen
asynchronen Prozeß, der hier nicht sichtbar ist" Der fragliche
asynchrone Prozess war in Deinem Beispiel mehr als sichtbar.


> Wenn ich etwas programmiere, durchdenke ich es stets gründlich:

Lobenswerter Vorsatz, wenn auch gelegentlich ineffizient.


> o Wie lange dauert "|| { :>....."? Sagen wir mal 1 us.

Ein fork und ein Wechsel in den Kernelcode (Dateisystem) in der Zeit?
Mutige Annahme. Zwar findet kein Plattenzugriff statt, aber dennoch.

Entscheidend ist aber nicht so sehr die Ausführungszeit. Ich kenne
den Scheduler nicht im Detail, aber ich halte es für Wahrscheinlich,
dass er bei solchen Prozessoperationen (wie dem fork hier) aktiviert
wird. Damit ist eine sehr beachtliche Wahrscheinlichkeit von
vielleicht 1-50% gegeben, dass der wpa-Prozess gerade dann aktiviert
wird. Voila. Ob der fragliche Shellcode dann 1µs oder 1 ms braucht,
ist nachrangig, wenn er erst danach ausgeführt wird...


> Damit sind wir bei 1:1000000 Wahrscheinlichkeit.

So viel mal dazu.


> o Dies auch nur, wenn wpa 1-mal pro Sekunde was schreibt.

Nein. Das nur dann, wenn wpa 1-mal pro Sekunde einen Fehlercode
rausschreibt.


> In der Praxis kann man oft mit solchen Wahrscheinlichkeiten leben.
> 10^10 Sekunden ist ein immens langer Zeitraum - über 300 Jahre.

Ja, ja, Intels 28.000 Jahre gegen IBMs 60 Tage, das kennen wir ja...


CU

Hauke
--
http://www.hauke-laging.de/ideen/
http://www.hauke-laging.de/software/
http://zeitstempel-signatur.hauke-laging.de/
Wie können 59.054.087 Leute nur so dumm sein?
.

[schmedi]

Hallo,

ich hab jetzt das folgende probiert:

#!/bin/sh

while true
do
wpa_supplicant -dd -g /var/run/wpa_supplicant-global 2>&1 | tee
/dev/tty |
grep -q "HEOCDRIVPRIV!" || wpa_cli terminate
done

Allerdings kann ich das jetzt aufgrund der while-Schleife nicht mit
strg-C beenden, das ist schon bissl nervig. Gibts da vielleicht noch
eine bessere Methode?
Danke!!

Gr=FC=DFe,

Andrea

.

[Andrea Scharfe]

Nochwas dazu,

die Ausgabe kommt bei dieser Methode jetzt in Sch=FCben. Gibt es da so
eine Art Buffergr=F6=DFe und immer wenn der voll ist wird das ausgegeben?
Ich h=E4tte aber gern, dass sofort, wenn der Fehler auftritt, der
Supplicant beendet wird, nicht erst wenn der Buffer dann voll ist.
Ist das jetzt in diesem Beispiel der Fall?

Gr=FC=DFe,
Andrea

.

[Andrea Scharfe]

> Mich wundert es, da=DF oben terminiert wird, wenn grep das Suchwort
> nicht gefunden hat.

Wieso das *gr=FCbel*?
Wenn grep etwas findet liefert es 0 zur=FCck, d.h. Success und dann
tritt die Oder Bedingung ein, oder sehe ich das falsch?

Gr=FC=DFe,
Andrea

PS die besseren Methoden muss ich mir nochmal in Ruhe anschauen, das
ist ja nicht ganz so einfach zu verstehen.

.

[Juergen P. Meier]

schmedi <schmedi [at] gmail.com>:
> da mir das letzte Mal hier so schnell geholfen wurde, habe ich gleich
> noch eine Frage:
>
> Ich möchte die Standard Fehler Ausgabe eines Programmes auf ein
> bestimmtes Kommando hin überwachen und wenn dort ein bestimmtes Wort
> auftaucht, soll etwas ausgeführt werden.
> Gleichzeitig sollen aber sowohl Standard Fehler als auch Standard
> Ausgabe immer auf der Konsole ausgegeben werden.
>
> Also Beispiel:
>
> programm 2>&1 |grep "suchwort" || aktion
>
> Alles Ausgaben von von Programm will ich aber auf der Konsole sehen.
> Wie kann ich das am günstigsten bewerkstelligen?
>
> Viele Grüße und danke!!

man tee

programm 2>&1 | tee /dev/tty | grep -q "suchwort" || aktion

HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
.

[Helmut Schellong]

Andrea Scharfe wrote:
> Nochwas dazu,
>
> die Ausgabe kommt bei dieser Methode jetzt in Schüben. Gibt es da so
> eine Art Buffergröße und immer wenn der voll ist wird das ausgegeben?
> Ich hätte aber gern, dass sofort, wenn der Fehler auftritt, der
> Supplicant beendet wird, nicht erst wenn der Buffer dann voll ist.
> Ist das jetzt in diesem Beispiel der Fall?

Pipes haben beispielsweise eine Größe von 5120 Byte ...


--
Mit freundlichen Grüßen
Helmut Schellong var [at] schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
.