Softpicks.Net Deutsch

[Helmut Schellong]

Thomas Rachel wrote:
> 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.

»bbb && ccc« ist also ein Kommando?

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

Jetzt plötzlich »bbb && ccc« als Einheit und gleichzeitig
getrennt betrachtet, je nach Exit.
Au weia.

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

Dort ja.

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

Und wieso lautet die man-Page ksh (HP-UX) anders, die ich bereits postete?


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

[Thomas Rachel]

Helmut Schellong wrote:

>>> -----------------------------------------------------------
>>> ''&&'' 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.
>
> »bbb && ccc« ist also ein Kommando?

Aus Sicht des ersten "&&" ja.

Nach der von Dir geposteten ksh-Beschreibung ist es "the list following
it[=the operator]", die evtl. ausgeführt wird.

> Jetzt plötzlich »bbb && ccc« als Einheit und gleichzeitig
> getrennt betrachtet, je nach Exit.

Aus Sicht des ersten && ist es eine Einheit, aus Sicht des zweiten && eben
nicht.


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

Abgesehen von der invertierten Logik arbeitet die Shell aber ja genauso.


> Und wieso lautet die man-Page ksh (HP-UX) anders, die ich bereits postete?

Sie mag anders lauten, aber das darin beschriebene Verhalten deckt sich zu
100% mit der Betrachtungsweise als Operatoren.


Thomas
--
Blödsinnige Liedtexte, Teil 3:
"Erzähle mir, norwegisches Mädchen, wie zu Eingabetaste Deine Welt..."
"Gryy zr, abejrtvny tvey, ubj gb ragre lbhe jbeyq..."
.

[Thomas Rachel]

Helmut Schellong wrote:

> Christian Garbs wrote:

>> 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.
>
> Nachfolgend wird für eine Korn-Shell beschrieben:
> [...] The symbol && (||) causes
> the list following it to be executed only if the preceding pipeline
> returns a zero (non-zero) value.

Ist das was anderes als KO-Logik?


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

Inwieweit weicht denn das tatsächliche Verhalten von dieser Beschreibung
(oder nennen wir es vielleicht: Betrachtungsweise) ab?



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

Sie ist AFAIK auch hier vom Standard vorgesehen; ein Funktionsaufruf, der
dank KO-Logik nicht auszuwerten braucht, darf auch nicht ausgeführt werden.
Ebenso ist es bei der Shell: Eine Pipeline wird nicht ausgeführt, wenn
aufgrund dieser KO-Logik die Abarbeitung der Liste vorher abgebrochen wird.


Die beiden Betrachtungsweisen (verkürzte IF-Abfrage oder Logikoperatoren mit
KO-Logik) sind semantisch äquivalent.


Thomas
--
Du verwexelst da was: Chinin ist das, was den Lemon bitter macht. Das,
was die BigMäcs und den Chefsalate so schön knackig macht, heißt Chitin.
Hartmut Lehmann in de.alt.folklore.urban-legends
.

[Thomas Rachel]

Martin Vaeth wrote:

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

Stimmt, Du hast recht. Da habe ich nicht weit genug gedacht. Allerdings
scheint mir das nur bei Mischung der verschiedenen Operatoren relevant zu
sein?

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

ACK.


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

ACK, darüber bin ich auch schonmal gestolpert.


Thomas
--
Das ist *MEINE* Signatur!
.

[Thomas Rachel]

Helmut Schellong wrote:

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

[...]

> Diese neuere Beschreibung ist Kokolores!

Im nachhinein betrachtet: Stimmt - aber nur wegen der auch von Dir erwähnten
Behauptung "executes the first command, and then executes the second
command if...", nicht jedoch wegen der Bezeichnung "... are AND-OR list
operators".

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

Wie Martin bereits schrieb: Wie erklärst Du Dir dann den negativen
Exitstatus von

false && <do_something>

im Gegensatz zu

if false; then do_something; fi

?

Denn auch und gerade dieser Unterschied ist es ja, was die Interpretation
als Operatoren so naheliegend macht.


Thomas
--
Das Fleisch war willig, aber das Gras war naß.
.

[Juergen Ilse]

Hallo,

Helmut Schellong <rip [at] schellong.biz> wrote:
> Heike C. Zimmerer wrote:
>> 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?

Du hast zwar recht, aber fuer "nicht C-Programmierer" ist es evt. leichter,
sich && als "execute upon success" und || als "execute upon failure" zu
merken (wie ich es mal in irgend einer Doku gelesen habe).

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

Bei "ueblichen" unix-shells passiert eben nichts "grundsaetzlich unter-
schiedliches" sondern wirklich (wie Heike schrieb) das *selbe*.

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

Das die bsh keine mit ueblichen unix-shells vergleichbare shell ist,
hatten wir schon mehr als einmal geklaert. Wenn du wenigstens darauf
verzichtet haettest, uebliche shell-Konstrukte in deinem Machwerk mit
voellig anderen Bedeutungen zu belegen (um diese Inkompatibilitaeten
dann auch noch als "Features" zu verkaufen) koennte man ja vielleicht
noch einmal darueber reden, aber so ...

Tschuess,
Juergen Ilse (juergen [at] usenet-verwaltung.de)
.

[Helmut Schellong]

Thomas Rachel wrote:
> Helmut Schellong wrote:

>> && und || sind für mich Syntaxsymbole, die den Verarbeitungsfluß steuern.
>> Eine Kurzform (&&) von: if aaa; then bbb; fi
>
> Wie Martin bereits schrieb: Wie erklärst Du Dir dann den negativen
> Exitstatus von
>
> false && <do_something>
>
> im Gegensatz zu
>
> if false; then do_something; fi
>
> ?

Daß das if-Kommando ein weiteres beteiligtes Kommando
ist, das den Exit setzen kann, habe ich still vorausgesetzt.


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

Juergen Ilse wrote:
> Hallo,
>
> Helmut Schellong <rip [at] schellong.biz> wrote:
>> Heike C. Zimmerer wrote:
>>> 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?
>
> Du hast zwar recht, aber fuer "nicht C-Programmierer" ist es evt. leichter,
> sich && als "execute upon success" und || als "execute upon failure" zu
> merken (wie ich es mal in irgend einer Doku gelesen habe).

Sagte ich auch schon:
Wenn schon Operator, dann Exit-TRUE-Op. und Exit-FALSE-op.

>> 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.
>
> Bei "ueblichen" unix-shells passiert eben nichts "grundsaetzlich unter-
> schiedliches" sondern wirklich (wie Heike schrieb) das *selbe*.

Bei der Abarbeitung der Sequenzen passiert also jeweils ein und dasselbe.
Einmal Shell-Flußsteuerung, einmal Kommando test.
Denk nochmal darüber nach.

>> -a ist tatsächlich ein Operator, der beide Vergleichsresultate UND-verknüpft.
>> (Beispielsweise in der bsh wird (abweichend) von rechts nach links gearbeitet.)
>
> Das die bsh keine mit ueblichen unix-shells vergleichbare shell ist,
> hatten wir schon mehr als einmal geklaert. Wenn du wenigstens darauf
> verzichtet haettest, uebliche shell-Konstrukte in deinem Machwerk mit
> voellig anderen Bedeutungen zu belegen (um diese Inkompatibilitaeten
> dann auch noch als "Features" zu verkaufen) koennte man ja vielleicht
> noch einmal darueber reden, aber so ...

"von rechts nach links" ist transparent.
Andere Bedeutungen gibt es kaum - wirklich!


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

Martin Vaeth wrote:
> Thomas Rachel <glglgl [at] expires-2006-09-30.arcornews.de> schrieb:
>> Helmut Schellong wrote:

> Zum "Beweis" dass && und || linksassoziativ sind (dies scheint
> nirgends dokumentiert zu sein, aber ich bin kein Kenner des Standards)

Falls es nirgends dokumentiert ist, dann weil in allen älteren
man-Pages der Begriff »Operator« vermieden wird.

Im Zusammenhang mit Operatoren kommen nämlich die Begriffe
Arithmetisch, Logisch, Assoziativität, Präfix, Postfix, Infix in's Spiel.

Diese scheinen gänzlich zu fehlen.
Offenbar orientieren sich alle älteren Manuals an der Ursprungsbeschreibung
von Steve Bourne von 1978, der »Operator« wohlweislich vermied:
=====================================================================
2.7 Control flow - if
[...]
The sequence

if command1
then command2
fi

may be written

command1 && command2

Conversely,

command1 || command2

executes command2 only if command1 fails. In each case the value returned
is that of the last simple command executed.


Appendix B - Meta-characters and Reserved Words
a) syntactic

|
pipe symbol
&&
'andf' symbol
||
'orf' symbol
;
command separator
;;
case delimiter
&
background commands
( )
command grouping
=====================================================================

Neuere Manuals hingegen orientieren sich offenbar an SUS.

Da hat wohl jemand entschieden:
"Ach was, das sind jetzt alles Operatoren, basta.
Und alle Texte pfriemeln wir so hin, das es irgendwie auskömmlich paßt."

Ich denke, ich habe jetzt wirklich klar gemacht, warum sich mir
mir ob Nachfolgendem die Nackenhaare aufstellen:
----------------------------------------------------
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.
----------------------------------------------------



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

> Ich denke, ich habe jetzt wirklich klar gemacht, warum sich mir
> mir ob Nachfolgendem die Nackenhaare aufstellen:

Doch, Helmut, ja. Es reicht. Völlig.

Bei Gelegenheit liest Du noch nach, was gemeinhin unter Operator
verstanden wird. Wenn es Deine Zeit erlaubt.
.

[Helmut Schellong]

Heike C. Zimmerer wrote:
> Helmut Schellong <rip [at] schellong.biz> writes:
>
>> Ich denke, ich habe jetzt wirklich klar gemacht, warum sich mir
>> mir ob Nachfolgendem die Nackenhaare aufstellen:
>
> Doch, Helmut, ja. Es reicht. Völlig.
>
> Bei Gelegenheit liest Du noch nach, was gemeinhin unter Operator
> verstanden wird. Wenn es Deine Zeit erlaubt.

Was ein Operator ist, weiß ich spätestens seit meinem Studium
vor mehreren Jahrzehnten.

Du würdest gerne auch Steve Bourne dazu auffordern, dies nochmal
nachzulesen?, der die Symbole && und || _nicht_ als Operatoren eingestuft hat,
sondern als Flußkontrolle in seinem if-Kapitel.

Der Satz:
"Doch, Helmut, ja. Es reicht. Völlig."
ist ein Verlegenheitssatz, wenn einem die soliden Argumente ausgegangen sind,
und läßt erkennen, daß Du 'es' nicht wahrhaben willst.


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

> Heike C. Zimmerer wrote:
>> Helmut Schellong <rip [at] schellong.biz> writes:
>>
>>> Ich denke, ich habe jetzt wirklich klar gemacht, warum sich mir
>>> mir ob Nachfolgendem die Nackenhaare aufstellen:
>> Doch, Helmut, ja. Es reicht. Völlig.
>> Bei Gelegenheit liest Du noch nach, was gemeinhin unter Operator
>> verstanden wird. Wenn es Deine Zeit erlaubt.
>
> Was ein Operator ist, weiß ich spätestens seit meinem Studium
> vor mehreren Jahrzehnten.
>
> Du würdest gerne auch Steve Bourne dazu auffordern, dies nochmal
> nachzulesen?, der die Symbole && und || _nicht_ als Operatoren eingestuft hat,
> sondern als Flußkontrolle in seinem if-Kapitel.

Ich sehe in der Tatsache, dass jemand einen bestimmten Begriff nicht
verwendet, genau das, was dort steht: keine Aussage darüber. Ich
unterhalte mich doch nicht ernsthaft über etwas, was jemand *nicht*
geschrieben hat.

Was ein Operator ist, lässt sich übrigens nachlesen. Dir sind
verständlicherweise momentan Stellen lieber, wo sich nichts darüber
findet. Auch aus der Tatsache, dass ich im Moment bestimmte
Bezeichnungen Dich betreffend hier nicht verwende, solltest Du
keine weiteren Schlüsse ziehen als dass Du sie nicht kennst.

> Der Satz:
> "Doch, Helmut, ja. Es reicht. Völlig."
> ist ein Verlegenheitssatz, wenn einem die soliden Argumente ausgegangen sind,
> und läßt erkennen, daß Du 'es' nicht wahrhaben willst.

Nö. Deine Reaktion ließ darauf schließen, dass ich das alles genauso
gut meinem Friseur hätte erklären können. m.a.W.: Es wird mir zu
blöd.
.