ubuntuusers.de

Habe ein Verzeichnis -oTest wie kann ich in das Verzeichnis wechseln oder löschen? Habe folgendes ohne Erfolg versucht.

1
2
3
4
5
6
7
8
9

$ cd "-oTest/"
bash: cd: -o: Ungültige Option.
cd: Aufruf: cd [-L|[-P [-e]] [-@]] [Verzeichnis]

$ cd '-oTest/'
gleiche Fehlermeldung wie oben

$ cd \-oTest/
gleiche Fehlermeldung wie oben

Mit Nautilus lässt sich das Verzeichnis löschen, Danke.

1

$ rm -r -- -oTest/

Danke, da wäre ich nie drauf gekommen.

cd ./-oTest/

san04 schrieb:

cd ./-oTest/

Das ist die nächstliegendste Lösung, finde ich. Damit vermeidet man den "-" am Anfang und verhindert verlässlich, dass der Pfad als Option interpretiert wird. Und man braucht auch keine weiteren kommandospezifischen Tricks wie "–" oder "-e" (bei grep), von denen es naturgemäß verschiedene gibt.

Generell sind führende Dashes=Minuszeichen=Binde/Trennstriche eine häufige Stolperfalle für Befehle, weswegen man sie nach Möglichkeit vermeidet.

Viele Programme verstehen das Doppelminus als Signal für "hier enden die Optionen", aber letztlich entscheidet das jedes Programm selbst, ob es sich an diese Konvention hält; ein eingebauter Mechanismus der Shell ist es nicht.

user_unknown schrieb:

[…] Viele Programme verstehen das Doppelminus als Signal für "hier enden die Optionen", aber letztlich entscheidet das jedes Programm selbst, ob es sich an diese Konvention hält; ein eingebauter Mechanismus der Shell ist es nicht.

Bei der Bash schon. Lt. Manpage dient -- offiziell zur optionalen Trennung von Optionen und anderen Parametern.

kB schrieb:

user_unknown schrieb:

[…] Viele Programme verstehen das Doppelminus als Signal für "hier enden die Optionen", aber letztlich entscheidet das jedes Programm selbst, ob es sich an diese Konvention hält; ein eingebauter Mechanismus der Shell ist es nicht.

Bei der Bash schon. Lt. Manpage dient -- offiziell zur optionalen Trennung von Optionen und anderen Parametern.

Welche Sektion?

Müsste dann nicht

1
2
3

> echo -e -- -n "foo\nbar"  
-n foo
bar

ausgeben? Es gibt aber

1
2

-- -n foo
bar

aus.

Und auch

1
2
3

/usr/bin/echo -e -- -n "foo\nbar"  
-- -n foo
bar

Als Programmierer weiß man, dass C, C++, Javaprogramme und gewiss unzählige mehr von der aufrufenden Shell nur ein Array Strings übergeben bekommt und die Shell keineswegs den Inhalt der Strings klassifiziert, nach Option, nach Argument, nach Dateien, die wirklich da sind, IP-Adressen oder was das Herz begehrt, selbst wenn sie eben noch Dateinamensexpansion erfolgreich betrieben hat. Und da die Shell solche Infos nicht liefert, kann auch niemand solche auswerten.

Das Programm selbst muss "–" auswerten, wenn es vorkommt, und kann es auswerten wie es will. Natürlich soll man die Konventionen übernehmen, wenn sie sinnvoll sind.

Kann es sein, dass Du Dich auf die Sektion "Options" beziehst?

• - A – signals the end of options and disables further option processing. Any arguments after the

  • - are treated as filenames and arguments. An argument of - is equivalent to –.

Da geht es um die Optionen, die die Bash beim Start übergeben bekommt, nicht um die Interpretation von Kommandos in der Bash. ☺

Zu den Shell-builtins finden wir weiter unten:

SHELL BUILTIN COMMANDS Unless otherwise noted, each builtin command documented in this section as accepting options preceded by - accepts – to signify the end of the options. The :, true, false, and test/[ builtins do not accept options and do not treat – specially. The exit, logout, return, break, continue, let, and shift builtins accept and process arguments beginning with - without requiring –. Other builtins that accept arguments but are not specified as accepting options interpret arguments beginning with - as invalid options and require – to prevent this interpretation.

aber das beschränkt sich auf Builtins.

Externe Programme sind zwar gut beraten, den Doppeldash als End-of-Options zu interpretieren, wenn nicht gute Argumente dagegen sprechen. Aber vielleicht sprechen hier und da gute Argumente dagegen und manche Programme benutzen ja auch eine ganz und gar abweichende Syntax (dd if=foo of=bar).

user_unknown schrieb:

[…] Welche Sektion?

OPTIONS

Müsste dann nicht

1 2 3

> echo -e -- -n "foo\nbar" -n foo bar

ausgeben?

Ja, das erwarte ich auch so. Der Teil -- sollte nicht ausgegeben werden.

Es gibt aber

1 2	-- -n foo bar

aus.

Deine Beobachtung stimmt und damit widerspricht das tatsächliche Verhalten dem dokumentierten. Also ein Bug.

[…] Kann es sein, dass Du Dich auf die Sektion "Options" beziehst?

• - A – signals the end of options and disables further option processing. Any arguments after the

  • - are treated as filenames and arguments. An argument of - is equivalent to –.

Ja.

Da geht es um die Optionen, die die Bash beim Start übergeben bekommt

Ja.

nicht um die Interpretation von Kommandos in der Bash. ☺

Ich habe in der Tat angenommen, dass es auch für jedes einzelne Kommando der Shell bash gilt, da diese ja in einer Subshell ausgeführt werden. Das ist vielleicht nicht ganz richtig, aber mit …

Zu den Shell-builtins finden wir weiter unten:

SHELL BUILTIN COMMANDS Unless otherwise noted, each builtin command documented in this section as accepting options preceded by - accepts – to signify the end of the options. The :, true, false, and test/[ builtins do not accept options and do not treat – specially. The exit, logout, return, break, continue, let, and shift builtins accept and process arguments beginning with - without requiring –. Other builtins that accept arguments but are not specified as accepting options interpret arguments beginning with - as invalid options and require – to prevent this interpretation.

aber das beschränkt sich auf Builtins.

… hast Du ja herausgefunden, dass es sehr wohl auch für die eingebauten Funktionen gelten soll:

$ LANG= type cd echo /usr/bin/echo 
cd is a shell builtin
echo is a shell builtin
/usr/bin/echo is /usr/bin/echo

cd verhält sich bzgl. -- gemäß der Dokumentation, das interne echo nicht, und das externe echo kennt lt. Dokumentation -- gar nicht. Das mag der Grund sein, warum sich auch das interne echo wie das externe verhält und damit der eigenen Dokumentation widerspricht.

Manchmal ist es besser, das eingeführte falsche Verhalten anderer zu imitieren als auf dem eigenen richtigen zu bestehen.

Also vielleicht doch kein Bug, sondern nur undokumentierte Ausnahme.

Das ist kein falsches Verhalten. Eine Shell die -- besonders behandelt wäre falsch, denn das wäre sehr unerwartet, weil nicht POSIX-konform und würde einen vor das Problem stellen wie man dann -- als Argument an ein Programm übergeben sollte. Das ---Argument gehört zur getopt()-API. Das muss jedes Programm selbst unterstützen, genau wie - als ”Dateiname” für Standardeingabe oder -ausgabe eine Konvention ist, die jedes Programm selbst unterstützen muss. Und es gibt auch viele Programme die weder das eine noch das andere kennen/unterstützen. Insbesondere solche die das argv-Array selbst auswerten statt eine Bibliothek/API dafür zu verwenden.

Marc_BlackJack_Rintsch schrieb:

... und würde einen vor das Problem stellen wie man dann -- als Argument an ein Programm übergeben sollte.

Na, nach dem –, also so:

1

foobar -i --debug -x 7 -y 9 -- -- 

☺

Ich stimme aber zu, dass es kein falsches Verhalten ist; nur eine Falle für oberflächliche Leser der Manpage, zu denen zuallererst ich selbst zähle.

@user_unknown: Als letztes Argument, okay. Und als erstes Argument? 🤔

Marc_BlackJack_Rintsch schrieb:

@user_unknown: Als letztes Argument, okay. Und als erstes Argument? 🤔

Sorry, ich verstehe die Frage nicht.

Sind wir hier immer noch on-topic?

@user_unknown: Du hast gezeigt wie man -- als letztes Argument übergeben kann. Aber wie übergibt man das als erstes Argument, also wenn da noch andere Argumente folgen sollen. Also wenn erst -- und dann -i --debug kommen soll ohne das die beiden ihre Bedeutung als Argument verlieren. foobar -- -- -i --debug geht ja dann beispielsweise nicht.