wlanicht 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,
falsch, laut Ausgangspost vom Tautologen:
>> Danach als root anmelden, und zum Test im root-Verzeichnis
folgenden
>> Befehl eingeben:
>>
>> rm * -rf
> löscht der Befehl wohl doch eher rekursiv ohne Warnungen oder
> Nachfragen auszugeben. (Sofern nicht zufällig noch eine Datei namens
> “–” irgendwo da rumliegt.)
Korrekt, durch die Sortierung ist “–” dann vor allen anderen Dateien
und die Optionen am Ende “-rf” werden als Dateiname betrachtet und
sorgen damit nur für eine Fehlermeldung.
> > 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.
Klar, aber der OP hat getrollt und die Troll-Antwort mit dem “rm *
-rf” ist schon übel bösartig, insbesondere wenn tatsächlich das ein
angehender Ubuntuuser liest und das ggf. für bare Münze nimmt.
> 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.
Deswegen entwickle ich meine Sachen POSIX konform und verlasse mich
nicht darauf, dass irgendwelche Sortierungen passen oder
Sonderzeichen bei Dateinamen von der Shell per “\”-Quote maskiert
werden.
> 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 … )
Jupp, genausowenig allerdings wie ein: rm -rf *
> > 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 *
> # ls /*/*/*
> -bash: /bin/ls: Argument list too long
Das gilt für die bash, nicht aber für eine Bourne Shell oder gar die
/sbin/sh - mir geht’s hier wirklich auch darum, dass sich die Leute
einen sauberen Umgang mit den Tools angewöhnen. Treffen sie im RL mal
auf ein anderes System, so kann diese Gewöhnung vom einfachen
Nicht-Funktionieren Fehlersuche bis zu echten Betriebsproblemen
führen.
> 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.
Genau für diese Fälle gibt’s ja xargs 
[Generierte Argumente in der Commandline]
> 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.
Ja und da genau das die Empfehlung ist und alle Argumente *nach* dem
“–” nicht als Option gewertet werden ist die Nutzung von Optionen
*nach* den Fileargumenten kontraproduktiv.
[Syntax in den Manuals]
> wobei wie gesagt Leute mit schlechten Absichten sich nicht nach
> irgendwelchen offiziellen Vorgaben richten werden
*grins* leider, deswegen muss man umso sauberer bei der
Programmerstellung arbeiten und zufällige oder absichtliche
Fehleingaben abfangen. Spätestens dann braucht man “–” und damit
sind die Optionen am Ende der Argumentliste unsinnig.
[Ungültiges Kommando]
> Sorry, irgendwo in den Dokumentationen wird das spezielle Verhalten
> der gnu-utilities und wie man es abschaltet wohl dokumentiert sein.
Ja, in “man 3 getopt” - nur wer sieht da wirklich nach?
> Es wäre extrem bescheuert, dieses spezielle Verhalten in jeder
> Manpage aufzuführen.
Warum wird es dann implementiert, wenn es ein Spezialverhalten
darstellt?
> Erstens sind die Manpages nicht eine Beschreibung bis ins letzte
> Detail, das wäre der Quellcode.
Was zugegeben ein Vorteil von OpenSource ist, aber nicht jeder
*Anwender* ist in der Lage C-Code korrekt zu interpretieren.
> 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.
Wo man aber nur das Verhalten mit den Optionen am Anfang dokumentiert
findet.
> Drittens würde die Manpage nur unnötig kompliziert.
Nein, ein Satz “options and other arguments could be used in mixed
sequence” oder ein “rm [OPTION]… FILE… [OPTION]…” für die
Syntax würde die 99% erschlagen wo jemand nicht die Optionen mitten
zwischen den Dateiargumenten “versteckt”.
> 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.
D’accord - auf Grund der von Dir oben angegebenen Empfehlung “–” zu
verwenden ist der Zwang die Optionen *vor* den Dateinamen anzugeben
sowieso schon vorhanden und alles andere wäre bereits schlechter
Programmierstil.
Irgendwie sind wir uns ja doch einig *grins*
Auch wenn ich keine allgemeine Diskussion über Programmierstil in der
Shell lostreten wollte.
der bit-popler
So long…
>