wlan> > 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.
nicht nötig, lieber ein kleines Zitat von Dir hier reinposten:
> rm * -rf
Und damit disqualifiziert man sich selbst, wenn man nicht mal weiß,
dass Optionen *vor* die Argumente gehören.
Sind keine Dateien - so der Normalfall - im Verzeichnis /, so
bekommst Du da nur einen Fehler “File not found” für “*” und “-rf”
Abgesehen davon, dass vom Verzeichnis / vorher nicht die Rede war,
löscht der Befehl wohl doch eher rekursiv ohne Warnungen oder
Nachfragen auszugeben. (Sofern nicht zufällig noch eine Datei namens
“–” irgendwo da rumliegt.)
> 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.
In einer Beschreibung, wie man das WLAN zum Laufen bekommt, ist das
Kommando “rm * -rf” sowieso bösartig.
Ich habe noch nicht gehört, dass sich Malware gerne an Standards oder
Konventionen hält. Im Gegenteil: Gerne wird dagegen verstossen,
wenn’s denn trotzdem funktioniert.
Er hätte natürlich auch schreiben können: rm –enable-lan –option /
-rf (wobei ich das jetzt nicht getestet habe und auch niemandem
empfehlen würde, obiges irgendwo einzugeben … )
> 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.
# ls /*/*/*
-bash: /bin/ls: Argument list too long
bei mir wird nichts ausgeführt, wenn die Argumentliste zu lang ist.
Vermutlich genau aus demselben Grund. Man macht lieber nichts und
schmeisst ne Fehlermeldung raus, als die Hälfte möglicherweise falsch
zu tun.
> 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?
Wobei es Dir in solchen Fällen nicht hilft, alle Optionen vor den
Argumenten zu schreiben. Einzig ein “–” hilft Dir in solchen Fällen,
und das ist auch die offizielle Empfehlung.
> 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.
wobei wie gesagt Leute mit schlechten Absichten sich nicht nach
irgendwelchen offiziellen Vorgaben richten werden
> > 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!”
Sorry, irgendwo in den Dokumentationen wird das spezielle Verhalten
der gnu-utilities und wie man es abschaltet wohl dokumentiert sein.
Es wäre extrem bescheuert, dieses spezielle Verhalten in jeder
Manpage aufzuführen.
Erstens sind die Manpages nicht eine Beschreibung bis ins letzte
Detail, das wäre der Quellcode.
Zweitens kann jeder, der die Manpage gelesen und verstanden hat, rm
bzw. andere Utilities umfassend benutzen und wenn man eine bestimmte
Funktionsweise wissen will, findet man die in der Manpage.
Drittens würde die Manpage nur unnötig kompliziert.
Viertens wäre es ein schlechter Programmier- bzw. Arbeitsstil, wenn
man sich darauf verlässt, dass Optionen hinter Argumenten nicht
beachtet werden. Dadurch würden sich in extremen Situationen auch
Fehler in Scripte bzw. Arbeitsweisen einschleichen, auch wenn rm
selbst Optionen hinter Dateinamen ignorierte.
> Hm, wusste ich nicht, hab ewig kein Linux gesehen, lade grade RH9
Keine Ahnung