Softpicks.Net Deutsch

[Helmut Schellong]

schmedi wrote:
> 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!!

Bessere Methoden wurden (prinzipiell) gezeigt.

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


--
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
.

[Helmut Schellong]

Andrea Scharfe wrote:
>> Mich wundert es, daß oben terminiert wird, wenn grep das Suchwort
>> nicht gefunden hat.
>
> Wieso das *grübel*?
> Wenn grep etwas findet liefert es 0 zurück, d.h. Success und dann
> tritt die Oder Bedingung ein, oder sehe ich das falsch?

Für Shell-TRUE steht &&, nicht ||.


--
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
.

[Helmut Schellong]

Andrea Scharfe wrote:
>> Mich wundert es, daß oben terminiert wird, wenn grep das Suchwort
>> nicht gefunden hat.
>
> Wieso das *grübel*?
> Wenn grep etwas findet liefert es 0 zurück, d.h. Success und dann
> tritt die Oder Bedingung ein, oder sehe ich das falsch?

Die Bezeichnungen AND und OR für && und || finde ich behämmert.
Es wird doch nichts undiert oder oderiert.

&& ||
TRUE FALSE
SUCCESS FAILURE

ist meiner Meinung nach korrekt.


--
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
.

[Helmut Schellong]

Andrea Scharfe wrote:

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

Ich halte das Konzept einer Pipe-Kette hier für grundsätzlich ungeeignet.


--
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
.

[Helmut Schellong]

Andrea Scharfe wrote:
> Oh dann habe ich das mit dem && und || komplett falsch verstanden.
> Danke für die Aufklärung
>
>> Ich halte das Konzept einer Pipe-Kette hier für grundsätzlich ungeeignet.
> Ok, ich probiere es mit deinem Vorschlag, sieht schonmal gut aus, mal
> sehen ob es den bösen Fehler auch wirklich abfängt.

Beachte aber die Voraussetzungen!

Niemand hier kennt das Verhalten und den Aufbau dieses
wpa-Dingens genau.


Bekannt ist auch:

tail -f log_datei | grep 'suchwort'

Aber das läuft dauerhaft und man muß die Ausgabe manuell beobachten
und irgendwann killen.
(log_datei wird von einem anderen Prozeß ständig nachgefüllt.)


--
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]

schmedi schrieb am Donnerstag 14 September 2006 13:39:

> grep -q "HEOCDRIVPRIV!" || wpa_cli terminate

Das hast Du also ausprobiert

[Hauke Laging]

Hauke Laging schrieb am Donnerstag 14 September 2006 16:15:

> schmedi schrieb am Donnerstag 14 September 2006 13:39:
>
>> grep -q "HEOCDRIVPRIV!" || wpa_cli terminate
>
> Das hast Du also ausprobiert? Ich habe doch schon erklärt, weshalb
> das so nicht geht...

OK, ich ziehe das zurück, mit -q verhält grep sich anders. Dennoch
kann dahinter nur && stehen, || ist sinnlos.


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:
> Hauke Laging schrieb am Donnerstag 14 September 2006 16:15:
>
>> schmedi schrieb am Donnerstag 14 September 2006 13:39:
>>
>>> grep -q "HEOCDRIVPRIV!" || wpa_cli terminate
>> Das hast Du also ausprobiert? Ich habe doch schon erklärt, weshalb
>> das so nicht geht...
>
> OK, ich ziehe das zurück, mit -q verhält grep sich anders. Dennoch
> kann dahinter nur && stehen, || ist sinnlos.

Es verbleibt noch das schwallartige Funktionieren
mit diesem Pipe-Konzept.

Niemand schließt seine Pipe-Schreibseite, somit werden Daten
nur per Schwall empfangen, wenn der Pipe-RAM-Puffer jeweils
voll ist.


--
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 16:57:

> Es verbleibt noch das schwallartige Funktionieren
> mit diesem Pipe-Konzept.
>
> Niemand schließt seine Pipe-Schreibseite, somit werden Daten
> nur per Schwall empfangen, wenn der Pipe-RAM-Puffer jeweils
> voll ist.

<ee8vsc$eo1$1 [at] online.de>
--
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?
.

[Christian Garbs]

Mahlzeit!

Helmut Schellong <rip [at] schellong.biz> wrote:

> Die Bezeichnungen AND und OR für && und || finde ich behämmert.
> Es wird doch nichts undiert oder oderiert.

Es basiert auf einfachsten Optimierungsansätzen bei der Auswertung von
Bedingungen:

Wenn ich eine Und-Verknüpfung (&&) habe, dann muss ich die zweite
Bedingung nur prüfen, wenn die erste TRUE war, ansonsten ist das
Ergebnis (FALSE) bereits bekannt.

Wenn ich eine Oder-Verknüpfung (||) habe, dann muss ich die zweite
Bedingung nicht mehr prüfen, wenn die erste bereits TRUE war - sie
würde nichts mehr am Ergebnis (TRUE) ändern.

Die zweite Bedingung entspricht dem zweiten Kommando, dessen
Ausführung dann entsprechend wegfällt.

Ist einfach herzuleiten und einfach zu merken.

Gruß,
Christian
--
.....Christian.Garbs.....................................http://www.cgarbs.de
Windows CE steht für "Crash Everywhere"
.

[Helmut Schellong]

Christian Garbs wrote:
> Mahlzeit!
>
> Helmut Schellong <rip [at] schellong.biz> wrote:
>
>> Die Bezeichnungen AND und OR für && und || finde ich behämmert.
>> Es wird doch nichts undiert oder oderiert.
>
> Es basiert auf einfachsten Optimierungsansätzen bei der Auswertung von
> Bedingungen:
>
> Wenn ich eine Und-Verknüpfung (&&) habe, dann muss ich die zweite
> Bedingung nur prüfen, wenn die erste TRUE war, ansonsten ist das
> Ergebnis (FALSE) bereits bekannt.
>
> Wenn ich eine Oder-Verknüpfung (||) habe, dann muss ich die zweite
> Bedingung nicht mehr prüfen, wenn die erste bereits TRUE war - sie
> würde nichts mehr am Ergebnis (TRUE) ändern.

Du beschreibst da die KO-Logik der dyadischen logischen Operatoren
der Sprache C.

Nchfolgend wird für eine Korn-Shell beschrieben:
A list is a sequence of one or more pipelines separated by ;, &, &&,
or ||, and optionally terminated by ;, &, or |&. Of these five
symbols, ;, &, and |& have equal precedence. && and || have a higher
but also equal precedence. A semicolon ( causes sequential
execution of the preceding pipeline; an ampersand (&) causes
asynchronous execution of the preceding pipeline (that is, the shell
does not wait for that pipeline to finish).
[...] The symbol && (||) causes
the list following it to be executed only if the preceding pipeline
returns a zero (non-zero) value. An arbitrary number of new-lines can
appear in a list, instead of semicolons, to delimit commands.

In einer Shell sind && und || keine Operatoren, die zwei Operanden
verknüpfen, sondern:

aaa
if [ $? -eq 0 ]; then bbb; fi

ist die lange Form von:

aaa && bbb

Obwohl es auch folgende Beschreibung gibt:
Short-Circuit List Operators
''&&'' and ''||'' are AND-OR list operators. ''&&'' executes the first
command, and then executes the second command if the exit status of the
first command is zero. ''||'' is similar, but executes the second com-
mand if the exit status of the first command is nonzero. ''&&'' and
''||'' both have the same priority.

so bin ich nicht damit einverstanden.

In C ist das anders:

a = f!=rks && f==sks;

Hier werden tatsächlich beide Vergleichsresultate per && verknüpft
und das Resultat an a zugewiesen.
Die KO-Logik dabei ist lediglich ein Zusatz, der unnötige Evaluation erspart.



--
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
.

[Helmut Schellong]

Heike C. Zimmerer wrote:
> Helmut Schellong <rip [at] schellong.biz> writes:
>
>> In einer Shell sind && und || keine Operatoren, die zwei Operanden
>> verknüpfen, sondern:
>>
>> aaa
>> if [ $? -eq 0 ]; then bbb; fi
>>
>> ist die lange Form von:
>>
>> aaa && bbb
>
> Sie sind keine Operatoren. Ah ja. Nur:
>
> if [ "$a" != "$b" ] && [ "$c" = "hallo" ]
>
> macht dasselbe wie
>
> [ "$a" != "$b" -a "$c" = "hallo" ]
>
> nämlich ein Verknüpfung zweier Operanden, und zwar lesbarer. So what?

Diese Herleitung taugt aber nicht. "macht dasselbe" ist schwammig.
Es entsteht letztlich die gleiche Wirkung aus diesen beiden Sequenzen,
jedoch innerhalb der Sequenzen geschieht etwas sehr Unterschiedliches.

-a ist tatsächlich ein Operator, der beide Vergleichsresultate UND-verknüpft.
(Beispielsweise in der bsh wird (abweichend) von rechts nach links gearbeitet.)

&& jedoch wertet den Exit von links aus und startet abhängig davon
das Kommando rechts oder eben nicht.
Links wird ein Exit-Wert ausgewertet, rechts wird eine Flußsteuerung vorgenommen.
Das sind für mich keine Merkmale eines binären Operators.

if (ausdruck) anweisung; ist in C die Analogie dazu.
Dabei sind »if« und »( )« und »;« _keine_ Operatoren!
Bei a*b/(c+3) sind »( )« ebenfalls _keine_ Operatoren, sondern
sie steuern die Verbeitungsreihenfolge.

Selbst wenn ich && und || mal doch als Operatoren anerkenne, so würde
ich sie keinesfalls als AND-OR-Operatoren benennen, sondern als
Exit-True-Operator und Exit-False-Operator.

[[ aa == bb && cc != dd ]] #ksh: wie nennt man && denn hier?!

> Dein Verständnis von "Operand" ist auch etwas überarbeitungsbedürftig.
> Eine Fünktion, deren Rückgabewert geprüft wird, ist kein Operand des
> &&-Ausdrucks? Aus Sicht der Operation ist es schnuppe, wie der Wert
> ihrer Operanden entsteht.

-----------------------------------------------------------
''&&'' and ''||'' are AND-OR list operators. ''&&'' executes the first
command, and then executes the second command if the exit status of the
-----------------------------------------------------------

true && bbb && ccc

Der erste && startet also bbb, und der zweite && startet bbb ebenfalls ...

false && bbb && ccc

Der erste && startet bbb nicht, jedoch der zweite && startet bbb ...

Diese neuere Beschreibung ist Kokolores!
Sie wurde 'rückwärts' hingewürgt, aufgrund von verkrampftem Wunschdenken.

&& und || sind für mich Syntaxsymbole, die den Verarbeitungsfluß steuern.
Eine Kurzform (&&) von: if aaa; then bbb; fi


> [...]

Überzeugt mich nicht.


--
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
.

[Heike C. Zimmerer]

Helmut Schellong <rip [at] schellong.biz> writes:

> Überzeugt mich nicht.

Ich hab's nicht anders erwartet,
.

[Thomas Rachel]

Helmut Schellong wrote:

>> Dein Verständnis von "Operand" ist auch etwas überarbeitungsbedürftig.
>> Eine Fünktion, deren Rückgabewert geprüft wird, ist kein Operand des
>> &&-Ausdrucks? Aus Sicht der Operation ist es schnuppe, wie der Wert
>> ihrer Operanden entsteht.
>
> -----------------------------------------------------------
> ''&&'' and ''||'' are AND-OR list operators. ''&&'' executes the first
> command, and then executes the second command if the exit status of the
> -----------------------------------------------------------
>
> true && bbb && ccc
>
> Der erste && startet also bbb, und der zweite && startet bbb ebenfalls ...

Nein. Der erste && startet bbb && ccc, nachdem, äh, true als true erkannt
wurde. Der zweite startet dann bbb und evtl. ccc.


> false && bbb && ccc
>
> Der erste && startet bbb nicht, jedoch der zweite && startet bbb ...

Und hier startet der erste bbb && ccc nicht. Dieser würde aber bbb und dann
ggf. ccc starten, wenn er denn zum Zuge käme.


> && und || sind für mich Syntaxsymbole, die den Verarbeitungsfluß steuern.
> Eine Kurzform (&&) von: if aaa; then bbb; fi

Das eine schließt das andere ja nicht aus.

Ich gehe davon aus, daß diese Schreibweise von C entliehen wurde. Dort sind
es tatsächlich logische Operatoren.

Die Interpretation des Exitcodes eines Prozesses mit 0=erfolgreich und !=0
als nicht erfolgreich und dann wiederum das logische Auswerten eines
Prozeßaufrufes nach den Maßstäben "hat geklappt" und "hat nicht geklappt"
unter Zuhilfenahme von 'short circuit evaluation', wie sie ja auch in C
geschieht, macht die Sache mit den logischen Operatoren wieder rund.


Thomas
--
Napoleon trug immer Rot, damit seine Soldaten nicht sehen konnten, wenn er
verwundet wurde. Die Nazis trugen braune Hosen... (unbekannte Quelle)
.

[Martin Vaeth]

Thomas Rachel <glglgl [at] expires-2006-09-30.arcornews.de> schrieb:
> Helmut Schellong wrote:
>>
>> true && bbb && ccc
>>
>> Der erste && startet also bbb, und der zweite && startet bbb ebenfalls ...
>
> Nein. Der erste && startet bbb && ccc, nachdem, äh, true als true erkannt
> wurde. Der zweite startet dann bbb und evtl. ccc.

Sorry, nein, da muss ich widersprechen:
&& und || sind *links*assoziative Operatoren ("Beweis" kommt weiter unten).
Man muss sich den obigen Ausdruck also so geklammert vorstellen:

{ true && bbb ; } && ccc

Mit anderen Worten: bbb wird gestartet (weil true eben einen erfolgreichen
Exit-Status liefert, und der Ausgang von bbb entscheidet dann über den
Exit-Status der ersten &&-Verknüpfung. Im Erfolgsfalle wird dann ccc
gestartet und dessen Exit-Status entscheidet über den gesamten Ausgang.

>> false && bbb && ccc
>>
>> Der erste && startet bbb nicht, jedoch der zweite && startet bbb ...
>
> Und hier startet der erste bbb && ccc nicht. Dieser würde aber bbb und dann
> ggf. ccc starten, wenn er denn zum Zuge käme.

Nein: Wegen der Linksassoziativität ist Obiges äquivalent mit
{ false && bbb; } && ccc
Zuerst wird die Klammer ausgewertet. Da "false" keinen erfolgreichen
Exitstatus hat, braucht bbb gar nicht erst ausgewertet zu werden.
Damit hat die Klammer keinen erfolgreichen Exitstatus, und ccc wird
ebenfalls nicht ausgewertet, und insgesamt liefert der Ausdruck keinen
erfolgreichen Exitstatus.

Zum "Beweis" dass && und || linksassoziativ sind (dies scheint
nirgends dokumentiert zu sein, aber ich bin kein Kenner des Standards)
betrachte die beiden Ausdrücke
false && true || echo 1
true || false && echo 1
die beide "echo 1" ausführen, was sie bei Rechtsassoziativität oder
wenn && oder || verschiedene "Bindungskraft" hätten, nicht beide dürften.

>> && und || sind für mich Syntaxsymbole, die den Verarbeitungsfluß steuern.
>> Eine Kurzform (&&) von: if aaa; then bbb; fi

Nicht ganz, denn wenn aaa keinen erfolgreichen Exit-Status hat, ist
der Exit-Status des if-Kommandos trotzdem erfolgreich.
.