Nach einer Phase der Neugier fielen mir neben den vielen Gemeinsamkeiten auch einige der Unterschiede auf - zunächst natürlich unangenehm, da man immer von dem Bekannten aus urteilt. Zu nennen wäre da vor allem anderen die striktere Syntax der meisten BSD-Befehle („cp VERZEICHNIS1 VERZEICHNIS2 -r“ ist nicht - Flags müssen vorne stehen). Mir ist dann aber aufgegangen, daß etwas striktere Handhabung keine schlechte Idee sein muß und daß die laxe GNU-Syntax ihren Preis hat, in diesem Fall das unschöne „--“, mit dem ich dem Befehl ggf. klarmachen muß, daß jetzt keine Flags mehr kommen (wenn ich z.B. einen Dateinamen mit einem Minus habe, was POSIX ja erlaubt).
Danke für den Einwurf! Ist immer interessant zu lesen, was alles POSIX ist (und ggf. was nicht). Ich mag das Doppelminus aber nicht wirklich. Um ehrlich zu sein hielte ich es für besser, kein Minus in Dateinamen zu verwenden (vor allem am Anfang...), aber dafür dürfte es zu spät sein.
Definitiv. Unter Unix ist ja in Dateinamen, wenn ich mich nicht irre, bis auf / und NUL alles erlaubt.
Wenn das Minus in einem Dateinamen nicht am Anfang steht, sehe ich da aber kein Problem. Ich nutze das oft, um Sinneinheiten in Dateinamen abzugrenzen, zum Beispiel den Autor vom Titel eines Dokuments. Statt Leerzeichen verwende ich natürlich Unterstriche.
Unix ist in dieser Hinsicht wie die Programmiersprache C, die ja eine gewisse Verbindung auch bzgl. der Erfinder und Ingenieure miteinander teilen.
Denn bei beiden gilt das Idiom, dass (fast) alles erlaubt ist, was möglich ist, selbst wenn die Konsequenz zum Nachteil des Anwenders ist. Es gibt unzählige Fallstricke und "guns to shoot oneself in the foot" aka "footguns". Der Vorteil ist jedoch, dass solche Werkzeuge sehr mächtig und vergleichsweise simpel sein können, was in gewisser Weise auch auf Unix und C zutrifft.
Wenn das Minus in einem Dateinamen nicht am Anfang steht, sehe ich da aber kein Problem.
Statt Leerzeichen verwende ich natürlich Unterstriche.
Ich komme auch mit Leerzeichen gut klar, nutze Sie aber selten und nur für private Dateien. Man muss sich nur häufig mehr Gedanken machen, besonders für Shell-Skripte, die man strikter verfassen muss, und die Shell-Vervollständigung hakt auch ab und an. Da ist jeder anders - zum Glück
Ich glaube, dass gemäß POSIX ein '-' an beliebiger Stelle im Dateinamen, der als optional option-argument beabsichtigt war, trotzdem als weiterer option-flag, geparst (steht sogar im Duden!) werden könnte, siehe Punkt 2 in Abschnitt 12.1 Utility Argument Syntax, auf welchen auch in Richtlinie 6 des oben erwähnten Abschnitt 12.2 Utility Syntax Guidelines explizit hingewiesen wird.
Ich habe das gerade nochmal gelesen und denke, dass das nicht der Fall ist.
Zunächst ist ja, was im Abschnitt 12.1 unter Punkt 2a und 2b steht, nur deshalb Teil des Standards, damit ältere Werkzeuge, deren Syntax nicht strikt dem folgt, was POSIX definiert, nicht gegen den Standard verstoßen.
Und selbst, wenn man es mit so einem Fall zu tun hätte, würde ein optionales Optionsargument, bei dem ein Minus zwar enthalten ist, aber nicht am Anfang steht, nicht als Option missverstanden werden. Und zwar aus einem einfachen Grund: ein Minus, vor dem kein Leerzeichen steht, wird nach POSIX nie als Option interpretiert, denn eine Option (ebenso wie eine Kombination mehrerer Ein-Buchstaben-Optionen) muss immer ein separates Argument sein (ob das zu ihr gehörige Optionsargument nun direkt dranhängt oder nicht).
Ich komme auch mit Leerzeichen gut klar, nutze Sie aber selten und nur für private Dateien. Man muss sich nur häufig mehr Gedanken machen, besonders für Shell-Skripte, die man strikter verfassen muss, und die Shell-Vervollständigung hakt auch ab und an.
Ja, deshalb empfiehlt es sich auch, in Shellskripten bei Kommandos, die irgendwas mit Dateien anstellen, deren Namen vorher nicht bekannt sind, immer das Doppelminus vor den Operandenteil zu setzen, also bspw.: mv -- "$datei_1" "$datei_2"
Das Doppelminus (oder wie immer man das richtig nennt) ist allerdings kein GNU-Spezifikum, sondern in POSIX als „Optionsendeindikator“ definiert.
Genauer gesagt, ist das für Fälle, in denen der erste Dateioperand mit einem Minus beginnt, also bspw.:
mv -- -doof dickDanke für den Einwurf! Ist immer interessant zu lesen, was alles POSIX ist (und ggf. was nicht). Ich mag das Doppelminus aber nicht wirklich. Um ehrlich zu sein hielte ich es für besser, kein Minus in Dateinamen zu verwenden (vor allem am Anfang...), aber dafür dürfte es zu spät sein.
Definitiv. Unter Unix ist ja in Dateinamen, wenn ich mich nicht irre, bis auf
/und NUL alles erlaubt.Wenn das Minus in einem Dateinamen nicht am Anfang steht, sehe ich da aber kein Problem. Ich nutze das oft, um Sinneinheiten in Dateinamen abzugrenzen, zum Beispiel den Autor vom Titel eines Dokuments. Statt Leerzeichen verwende ich natürlich Unterstriche.
Unix ist in dieser Hinsicht wie die Programmiersprache C, die ja eine gewisse Verbindung auch bzgl. der Erfinder und Ingenieure miteinander teilen.
Denn bei beiden gilt das Idiom, dass (fast) alles erlaubt ist, was möglich ist, selbst wenn die Konsequenz zum Nachteil des Anwenders ist. Es gibt unzählige Fallstricke und "guns to shoot oneself in the foot" aka "footguns". Der Vorteil ist jedoch, dass solche Werkzeuge sehr mächtig und vergleichsweise simpel sein können, was in gewisser Weise auch auf Unix und C zutrifft.
Ich glaube, dass gemäß POSIX ein '-' an beliebiger Stelle im Dateinamen, der als optional option-argument beabsichtigt war, trotzdem als weiterer option-flag, geparst (steht sogar im Duden!) werden könnte, siehe Punkt 2 in Abschnitt 12.1 Utility Argument Syntax, auf welchen auch in Richtlinie 6 des oben erwähnten Abschnitt 12.2 Utility Syntax Guidelines explizit hingewiesen wird.Ich komme auch mit Leerzeichen gut klar, nutze Sie aber selten und nur für private Dateien. Man muss sich nur häufig mehr Gedanken machen, besonders für Shell-Skripte, die man strikter verfassen muss, und die Shell-Vervollständigung hakt auch ab und an. Da ist jeder anders - zum GlückJa, C... Wer's kann, hat's gut.
Ich habe das gerade nochmal gelesen und denke, dass das nicht der Fall ist.
Zunächst ist ja, was im Abschnitt 12.1 unter Punkt 2a und 2b steht, nur deshalb Teil des Standards, damit ältere Werkzeuge, deren Syntax nicht strikt dem folgt, was POSIX definiert, nicht gegen den Standard verstoßen.
Und selbst, wenn man es mit so einem Fall zu tun hätte, würde ein optionales Optionsargument, bei dem ein Minus zwar enthalten ist, aber nicht am Anfang steht, nicht als Option missverstanden werden. Und zwar aus einem einfachen Grund: ein Minus, vor dem kein Leerzeichen steht, wird nach POSIX nie als Option interpretiert, denn eine Option (ebenso wie eine Kombination mehrerer Ein-Buchstaben-Optionen) muss immer ein separates Argument sein (ob das zu ihr gehörige Optionsargument nun direkt dranhängt oder nicht).
Ja, deshalb empfiehlt es sich auch, in Shellskripten bei Kommandos, die irgendwas mit Dateien anstellen, deren Namen vorher nicht bekannt sind, immer das Doppelminus vor den Operandenteil zu setzen, also bspw.:
mv -- "$datei_1" "$datei_2"Ja, stimmt. Ich denke, dass Sie Recht haben.
Touché