On Thu, Feb 06, 2003 at 09:19:39PM +0100, Bernhard Schiffner wrote:

On Wednesday 05 February 2003 19:58, Josef Spillner wrote: ...

...

Jetzt wo KDE 3.1 in incoming ist, gibt es auch für nicht besetzte Rechner was zu tun :) Wobei es denke ich effizienter ist, eher die kleinen Projekte anzugehen.

Josef

Beim Compilieren mit distccd stürzt mit häufig die Sache auf dem Slave ab. Neustart des inetd hilft.

Bernhard (Ob ich komme, weiß ich nicht, vielleich ist da aber ein kleiner Tip für squashing. Compiler-Leistung wird ja immer gebraucht...)

Hut ab, du traust uns eine ganze Menge zu. Compiler-Optimierung traue ich mir nicht zu. Ehrlichgesagt, ich glaube nicht, dass einer auf dieser Liste innerhalb eines Tages Verbesserungen am GCC machen könnte.

Bei mir auf der Liste stehen noch ein paar andere Dinge. Als ich mal Schulungen gegeben habe, ist mir aufgefallen, dass viele Kommandozeilen Tools schlecht dokumentiert sind. Es fehlt of nur ein kleines Beispiel:

help let

...

--> Dort wird zwar alles schön beschrieben, aber ein kleines Beispiel, wie z.B:

i=5 let "i=i+3" echo $i

wäre sinnvoll. Ich habe mich bei der ersten Begegnung mit dem Befehl sehr geärgert, dass kein Beispiel in der Hilfe zu finden ist.

Ein paar andere Sachen stehen noch im Palm-Pilot unter "Compi Projekte".

thomas

On Thu, Feb 06, 2003 at 11:54:36PM +0100, Reinhard Foerster wrote:

On Thu, 06 Feb 2003 22:52:24 +0100, Thomas Guettler wrote: Beispiele sind für Weicheier. Wenn die Funktion des Programms korrekt beschrieben ist, sind Beispiel nicht nötig. Das scheint mir jedenfalls die Philosphie in klassischen Unix manpages zu sein.

Das sehe ich anders. AIX ist z.B. einiges klassischer als Linux. Dort sind jedoch meistens Beispiele in den Man-Pages.

Beispiele kann man woanders finden. Ich würde solchen Ballast aus der manpage rauslassen. Eventuell macht eine 2. manpage mit Beispielen Sinn wie z.B. procmailex für procmailrc.

Ein bis zwei Beispiele halte ich für angebracht. Gerade bei dem Befehl let hat bestimmt jeder als erstes:

guettli@sonne:~$ let i = i + 1 bash: let: =: syntax error: operand expected (error token is "=")

geschrieben. Das funktioniert aber nicht, es heißt "i = i + 1".

thomas

On Fri, 07 Feb 2003 07:34:20 +0100, Thomas Guettler wrote:

Ein bis zwei Beispiele halte ich für angebracht. Gerade bei dem Befehl let hat bestimmt jeder als erstes:

guettli@sonne:~$ let i = i + 1 bash: let: =: syntax error: operand expected (error token is "=")

geschrieben. Das funktioniert aber nicht, es heißt "i = i + 1".

*argl* Wenn man die Hilfe gar nicht liest, sollte man besser nicht über sie meckern. Du hast von "help let" gesprochen, welches sagt:

let: let arg [arg ...] Each ARG is an arithmetic expression to be evaluated.

Willst du etwa sagen, daß du die Operatoren = und + für arithmetische Ausdrücke hälts? Zu was evaluiert der Ausdruck = denn deiner Meinung nach.

Und weil man ja = und + auch anderes definieren könnte als üblich, steht ein paar Zeilen tiefer in der Hilfe:

The following list of operators is grouped into levels of equal-precedence operators. The levels are listed in order of decreasing precedence.

-, + unary minus, plus ... =, *=, /=, %=, +=, -=, <<=, >>=, &=, ^=, |= assignment

Sorry, aber wer Hilfen sowieso nicht liest, profitiert auch nicht von enthaltenen Beipielen. Bloat ist kein Mittel gegen Leseresitenz

Reinhard

On Fri, 07 Feb 2003 10:37:36 +0100, Christian Helmuth wrote:

...

Willst du etwa sagen, daß du die Operatoren = und + für arithmetische Ausdrücke hälts? Zu was evaluiert der Ausdruck = denn deiner Meinung nach. [...]

Naja, spitzfindig ist das schon, oder?

Wenn du den Unterschied zwischen Funktion und Nichtfunktion als Spitzfindigkeit betrachtest - ja.

Mir als Anfänger in Sachen "let" hat das Beispiel geholfen. Dein Posting dagegen musste ich 2x lesen.

Wenn du nicht versuchst, Doku zu verstehen, wirst du auf immer und ewig aus Beispielen etwas zusammenfrickeln müssen. Langfristig ist diese Methode nicht toll.

Reinhard

On Fri, 07 Feb 2003 17:54:41 +0100, Thomas Guettler wrote:

Stell dir vor, du willst jemand, der kaum Deutsch versteht erklären was ein Fuß ist. Das einfachste ist doch, mit dem Finger darauf zu deuten und "Fuß" zu sagen. Klar, "unterster Abschnitt der Beine der Wirbeltiere, beim Menschen und den Affen nur der beiden hinteren (unteren) Gliedmaßen" wäre die, dem Brockhaus entsprechende, Beschreibung.

Gutes Beispiel. Und wenn du den Probanten danach vor ein Pferd stellst und das Wort "Fuß" murmelst, wird er aufs Maul zeigen. Er hat wohl Fuß=stinkt gelernt. Fuß=Turnschuh wird beim Pferd meist scheitern und mit Fuß=unten würde er lediglich einen Zufallstreffer landen, was auch nicht Sinn der Sache ist.

Ich mag Argumentationsketten nicht, die so starten: "Der Anwender ist dumm und lernunfähig. Der Anwender soll trotzdem das volle Potential von Programm/Gerät $NAME nutzen können. Deshalb müssen wir ihm Zucker in den Popo blasen, indem wir ..."

Warum nicht einfach sagen "Bevor du dich mit $THEMA beschäftigst, solltest du wenigstens schonmal was von $ANDERES_THEMA gehört haben? Gehe zu $VERWEIS_AUF_ANDERES_THEMA und komme wieder, wenn du das dort geschriebene wenigstens ansatzweise kapiert hast." Eventuell wird in $ANDERES_THEMA auf $DRITTES_THEMA verwiesen usw.

Damit könnte man ziemlich viel Aufwand einsparen. Der Anwender kommt am Anfang zwar erst ein paar Stunden/Tage später zum Ziel, ist aber beim nächsten Problem schon schlauer als am Anfang. Dem Anwender werden noch viel Dinge begegnen, die $ANDERES_THEMA und damit $DRITTES_THEMA voraussetzen. Er kann sich dann sparen, dort nochmal zu lesen.

Reinhard

Thomas Guettler wrote:

Hi LUG,

[...]

Darum geht es ja. "Ein Bild sagt mehr als tausend Worte". Ich kann mir gut vorstellen, dass 90% der Bevölkerung "+" für einen algebraischen Ausdruck halten.

Stell dir vor, du willst jemand, der kaum Deutsch versteht erklären was ein Fuß ist. Das einfachste ist doch, mit dem Finger darauf zu deuten und "Fuß" zu sagen. Klar, "unterster Abschnitt der Beine der Wirbeltiere, beim Menschen und den Affen nur der beiden hinteren (unteren) Gliedmaßen" wäre die, dem Brockhaus entsprechende, Beschreibung.

Um mal noch ein bissel Stoff für Reinhard zu liefern, würde ich gern noch das Beispiel des Auto anführen.

90% der Auto-Fahrer wissen nur das, was sie während des praktischen Teils der Fahrschule durch zeigen erlernt haben. Sprich Autoschlüssel nehmen, ins Schloß stecken und rumdrehen. Von diesen wird keiner Wissen, wie die Servo-Lenkung oder der Motor im Detail funktionieren (z.B. wie der Assemblercode der elektronischen Zündung aussieht). Das ist auch für die Fortbewegung garnicht nötig. Das Erfahrungswissen genügt dafür vollauf. Für den Rest gibt es die Autowerkstatt um die Ecke.

Dort ist dann das Kopfwissen gefragt. Sprich, welche Teil greifen wie und warum ineinander.

Ich persönlich finde beide Teile auch bei Software sehr wichtig. Warum sollte ich zum Ausschneiden ein Spalte in der Ausgabe von "ps" gleich die gesamte awk- oder perl-Funktionen lernen ? Das ist einfach verschwendete Zeit, das Beispiel aus der manpage entsprechend angepasst genügt vollauf.

Bei komplexeren Sachen dagegen ist es wichtiger zuerst die Teilkomponenten und deren Zusammenspiel zu kennen, da man sonst das Gesamtsystem nicht ohne wochenlanges probieren zum laufen bekommt.

Gruß,

Thomas

Bye,

Jens

Jens Lorenz wrote:

Ich persönlich finde beide Teile auch bei Software sehr wichtig. Warum sollte ich zum Ausschneiden ein Spalte in der Ausgabe von "ps" gleich die gesamte awk- oder perl-Funktionen lernen ? Das ist einfach verschwendete Zeit, das Beispiel aus der manpage entsprechend angepasst genügt vollauf.

Wenn Du die *Prinzipien* von Perl oder awk, die bei der Verarbeitung von ASCII-Dateien wichtig sind, einmal verstanden hast, kannst Du auch an Beispielen weitermachen. Das wirst Du aber nicht wollen. Denn so viele Beispiele kann es gar nicht geben, dass sie Deinen Anforderungen genuegen. Zum Thema "auswendig wissen": Alle Funktionen von awk hab ich auch nicht im Hinterkopf, schliesslich gibt es genug Moeglichkeiten zum Nachschlagen. Und wozu waeren gespeicherte Funktionen sonst da, wenn nicht zum Nachschlagen und Wiederverwenden? Alle Funktionen/Optionen/Shell-Befehle, die ich oft brauche, schleifen sich bei mir aber ein.

Stefan

.

On Sun, 09 Feb 2003 11:22:58 +0100, Thomas Guettler wrote:

Ich habe am Wochenende mehrere Leute befragt. Sie hielten alle das Pluszeichen für einen algebraischen Ausdruck.

Dann hast du wohl gefragt "Ist + ein algebraischer Ausdruck?" und nicht "Was ist +?" Auf die Idee, die 2. Frage mit "algebraischer Ausdruck" zu antworten, ist bei mir niemand gekommen :-) Aber es geht ja nicht um Meinungsumfragen.

let: let arg [arg ...] Each ARG is an arithmetic expression to be evaluated.

Also könnte man die Hilfe so verstehen:

let arg1 arg2 arg3 arg4

let i = i + 1

dann würde man auch "let + + = = + + +" für gültig halten. Da ein operator (+) aber eben keine expression ist, geht das nicht. Bei "let i = i + 1" genauso. + und = sind keine expressions.

Für Nichtinformatiker:

Bei der Beschreibung von Sprachen haben sich für die Bezeichnung der einzelnen Elemente bestimmte Bezeichnungen eingebürgert. Die tauchen immer wieder in manuals auf. Die Zuweisung per let in der Shellprogrammierung mit ein paar einfachen Rechnungen könnte als sog. "Grammatik" etwa so definieren: (Die rechten Seiten sind zeilenweise als Alternativen zu vestehen) ---------------------------------- statement := let_statement if_then_else_statement while_statement usw.

let_statement := let seperator expression_list

expression_list := expression expression_list seperator expression

expression := simple_expression expression binary_operator expression unary_operator expression assignment

assignment := identifier equal_sign expression

simple_expression := number variable

seperator := SPACE TAB

binary_operator := + - *

unary_operator := ~

equal_sign := =

variable := $ identifier -----------------------------------

[Ein paar Dinge habe ich weggelassen. identifier sei eine Buchstabenfolge, number eine Ziffernfolge. Man müsste einiges umbauen um z.B. die Reihenfolge der Errechnung von "let x=2+4*$a-~55" festzulegen.]

Wenn man nun wissen will, ob eine bestimmte Anweisung erlaubt ist, geht man von "statement" aus und ersetzt "statement" durch eine der rechten Seiten. Hier kommt nur "let_statement" in Frage. Darin ersetzt man dann wieder etwas und darin wieder usw. Irgendwann sollte man zu seiner gewünschten Anweisung kommen. Wenn das nicht geht, war die Anweisung falsch.

Beispiel zur Erzeugung von "let x=2+$a 3+4": (Das pro Schritt zu ersetzende Symbol ist immer mit ^ gekennzeichnet)

statement ^ let_statement ^ let seperator expression_list ^ let SPACE expression_list ^ let SPACE expression_list seperator expression ^ let SPACE expression_list SPACE expression ^ let SPACE expression SPACE expression ^ let SPACE assignment SPACE expression ^ let SPACE identifier equal_sign expression SPACE expression ^ let SPACE identifier = expression SPACE expression ^ let SPACE x = expression SPACE expression ^ let SPACE x = expression binary_operator expression SPACE expression ^ let SPACE x = expression + expression SPACE expression ^ let SPACE x = simple_expression + expression SPACE expression ^ let SPACE x = number + expression SPACE expression ^ let SPACE x = 2 + expression SPACE expression ^ let SPACE x = 2 + simple_expression SPACE expression ^ let SPACE x = 2 + variable SPACE expression ^ let SPACE x = 2 + $ identifier SPACE expression ^ let SPACE x = 2 + $ a SPACE expression

... nun ist nur noch die rechte expression zu "3+4" auflösen. Man erhält dann die vorgegebene Anweisung "let x=1+$a 3+4" als:

let SPACE x = 2 + $ a SPACE 3 + 4

Das Prinzip sollte erkennbar sein. So geht die Shell (oder ein Compiler) vor, wenn sie/er testet, ob die Anweisung gültig ist. "let +++" oder "let i = 1 + 1" sind mit der gegebenen Grammatik nicht zu erzeugen und somit falsch. Ihr könnt das ausprobieren. Es ist also wirklich sehr wichtig, ob + nun ein operator oder eine expression ist.

Mit diesem Prinzip im Hinterkopf sollten sich "man bash" oder "man awk" sehr leicht erschliessen lassen. Alle Sprachen (Programmiersprachen und natürlich Spachen) lassen sich so beschreiben.

Ich denke, dass die Hilfe so geschrieben sein sollte, dass man nicht im Bronnstein nachschlagen muss.

IMO sind Grammatiken und Sprachen das einzige, was die Informatik über die Mathematik hinaus "erschaffen" hat. Im Bronstein steht dazu vermutlich nichts.

Reinhard

On Mon, 10 Feb 2003 20:53:27 +0100, Jens Lorenz wrote:

Und siehe da, Reinhard du nutzt zur Erklärung ein Beispiel zusätzlich zu deiner Grammatik. Dabei wäre doch deine Grammatik vollkommen ausreichend und das Beispiel beschreibt auch nur eine der 42 Millionen Möglichkeiten.

Warum hast du ein Beispiel zur Verdeutlichung gewählt ? Und warum sollte in man pages nicht auch ein Beispiel zur Verdeutlichung stehen (nach der Grammatik zum Beispiel) ?

manpages oder ähnliche Onlinedoku (z.B. cmd --help) sollen eine Referenz zum jeweiligen Thema sein, kein Lehrbuch. Ich habe hier *keine* manpage geschrieben, sondern eine email. Kannst oder willst du den Unterschied nicht entdecken? Niemand hat hier gefordert: "Schafft alle Beipiele ab!" Ich habe lediglich dafür geworben, manualpages nicht *unnötig* aufzublasen, nur in dem Irrglaube, dadurch auch weitestgehend leseresitente Nutzer befriedigen zu können. Vielleicht liest du den Thread nochmal.

Thomas beharrt weiter darauf, nach eigenem Gusto das explizit als Operator definierte + als Ausdruck umdeuten zu dürfen und wundert sich dann, daß die nach seiner (falschen) Auslegung möglichen Anweisungen nicht funktionieren. Sein Fazit: Die Doku ist ungenügend.

Statt nun einfach zu versuchen, die manualpage zu verstehen, argumentiert er mit Meinungsumfragen zur Bedeutung eines +, was mich natürlich wenig beeindruckt. Deshalb habe ich versucht zu erklären, wie die manualpage gemeint ist, insbesondere, daß Begriffe wie expression, operator usw. nicht willkürlich verwendet wurden und nicht beliebig gegeneinander austauschbar sind. Die Manpage enthält also deutlich mehr Informationen, als Thomas in ihr entdeckt hat. Vielleicht sieht er sie jetzt. Wenn nicht - ist mir auch egal. Da gibt man sich Mühe, mal etwas wirklich ausführlich zu erläutern und dann sowas. *plonk* *kopfschüttel*

Reinhard

Hallo Leute,

Inzwischen gibt es doch eine gute Anzahl von Interessenten. Noch mal einige Informationen zusammengefasst:

Die Veranstaltung findet am 8. März im A-Gebäude, Andreas-Schubert-Str. 23, Zimmer 617--619 statt und könnte meines Erachtens um 10:00 Uhr beginnen (andere Vorschläge?). Ich lasse die Haustür bis 10:30 Uhr offen. Wer später kommt, müsste sich telefonisch bei mir melden. Parken kann man hinterm Gebäude im Hof.

Wie gesagt, 5 Rechner sind da, deren Linux-Partitionen im Prinzip auch geplättet werden können, wenn zum Schluss wieder alles in Ordnung gebracht wird (rsync von vorhandenem Masterrechnung oder so). Wer einen eigenen Rechner mitbringt, sollte auch Stromverteiler und Ethernetkabel nicht vergessen. Ein kleiner Hub oder Switch ist bereits angekündigt. Wenn ich richtig gerechnet habe, stehen 22 zusätzliche IP-Adressen per DHCP zur Verfügung. Ein paar Ports sind noch frei sowie ein WLAN-AP und 2 WLAN-Karten vorhanden -- WEP soll ja für ca. einen Tag brauchbar sein.

Geschirr, Kaffeemaschine, Wasserkocher, Kühlschrank und Mikrowelle sind da. Besteck ist etwas Mangelware, also besser selbst mitbringen. Ein Netto ist über die Straße, so dass wir uns dort eindecken können und man nicht unbedingt was mitbringen muss. Am Wochenende wird nicht geheizt. Je nach Wetter sollte man vorsichtshalber nicht zu wenig Klamotten anziehen oder mitbringen.

Ein paar Links:

http://www.tu-dresden.de/vkiwv/vwista/location.html#a-building http://www.debian.de/devel/ http://www.debian.org/Bugs/ http://bugs.debian.org/release-critical/ http://www.debian.de/devel/wnpp/ http://qa.debian.org/developer.php http://www.debian.de/devel/todo/

Torsten