wlan-funktek

> Die Frage habe ich schon beantwortet, was Du hättest erlesen können.
Anderer Thread - war eine andere zeitlich Abfolge > Bei dem Beispiel ist eine Reihenfolge angegeben, da eine Reihenfolge
> gewählt werden muss. Die Reihenfolge empfinde ich auch als schöner,
> ist aber nicht nötig.
Es ist nicht nur eine Reihenfolge die man wählen *kann*, die
Reihenfolge von Optionen und weiteren Argumenten ist seit langer Zeit
bei Unix-Kommandos vorgegeben.
Wenn Du meinst, dass das eine *optionale* Reihenfolge ist, dann
kannst Du mir sicher eine Stelle nennen, die den Kommandoaufruf so
spezifiziert, dass Optionen und andere Argumente wechselweise in
anderer Reihenfolge auftreten dürfen.
Das kurz aufgelistete ist kein “Beispiel” sondern die offizielle
Hilfe von “rm”, ich kann Dir auch gerne die man-page hier rein
kopieren.
Wenn ein Kommando somit von der offiziell vorgegebenen Syntax für die
Anwendung abweicht, so ist das nicht nur ein Schönheitsfehler,
sondern kann extreme Seiteneffekte nach sich ziehen.
Ein Beispiel:
Jemand will im aktuellen Verzeichnis alle seine Dateien löschen, es
sind eine Unmenge Dateien mit langen Namen - aber nur mit Nachfrage,
er gibt daher an:
$ rm -i *
Was passiert normalerweise:
Er wird bei jeder Datei gefragt ob sie gelöscht werden soll, ggf.
werden die letzten Dateien weil bei der Dateinamenexpansion von “*”
der Puffer der Shell-Commandline überschritten wird nicht mehr
abgefragt, aber auch nicht gelöscht.
Was passiert bei Angabe von “rm * -i”:
Es werden alle Dateien einfach gelöscht, da bei der
Dateinamenexpansion möglicherweise die Option “-i” nicht mehr in die
Shell-Commandline passt. Die Auswertung der Dateinamensexpansion wird
von der Shell durchgeführt, während die Auswertung der Optionen von
jedem Kommando selbst gemacht wird.
Klar kann man den Commandline-Buffer-Overflow mit “find … | xargs”
häufig umgehen oder das eher ineffiziente “find … -exec … \;”
einsetzen, aber wieviele Leute die gerade mal die einfachen Befehle
kennen wenden xargs an?
Und das schlimmste Gegenbeispiel dürfte dann die Bearbeitung von
Dateien sein die auf Grund einer Commandline-Substitution - z.B.
eines Dateiinhalts - generiert werden. Wie schließt Du ausser durch
die Position dann aus, dass da nicht versehentlich Dateinamen stehen
die aber wie eine Option aussehen?
> Wenn Du also einen Poster disqualifizierst, solltest Du dich auch
> informieren.
Ja, ich gebe zu, ich bin vermutlich schon zu lange im Unix-Umfeld
tätig, da schleift sich so etwas wie eine korrekte Syntax einfach
ein.
Bei jeglicher Art von Programmiersprache und dazu gehört auch die
Shell und die Unix-Befehle *muss* eine definierte Syntax und
Auswertungsfolge vorliegen, da ansonsten die Ergebnisse nicht mehr
unbedingt deterministisch sind.
Das Ausprobieren von Kommandos und das “zufällige” Funktionieren
einer von der korrekten Syntax abweichenden Parameterfolge zähle ich
nicht zu den typischen Informationsquellen. Die Beschreibung der
Syntax in den Manuals dagegen schon.
> Ich denke, der Poster wollte einfach mal eine andere, korrekte
> Schreibweise wählen, was wohl doch für viel Verwirrung gesorgt hat.
Anscheinend ist das verwirrend, denn keines der Kommandos aus den Gnu
coreutils (oder den alten fileutils) oder gar der ursprünglichen
Unix-Kommandos sieht diese Schreibweise vor, zumindest weder in der
integrierten Hilfe, noch in den Man-Pages!
Somit: “Sorry, das ist kein gültiges Kommando!”
Das einzige was damit möglich wäre, dass ein fleissiger Entwickler
die getopt Funktion so geändert hat, dass die Optionen an beliebiger
Stelle stehen können, dies aber den Entwicklern *aller* Programme die
sich darauf abstützen nicht bekannt ist - abgesehen davon, dass es
zusätzlich Zeit kostet *alle* Argumente zu parsen ob da nicht doch
irgendwo noch eine Option dazwischen ist, statt den Anfang der
Argumente zu parsen und jede erkannte Option zu berücksichtigen und
durch einen “shift” (bzw. –argc und argv in C) aus der Liste der
Argumente zu entfernen.
der bit-popler