Bashscript und Dateipfade

[The Hit-Man]

Ich übergebe gerade meinem Bashscript einen Dateinamen, dessen Pfad und auch Dateiname, Lehrzeichen enthält. Dcoh will ich mir den Filenamen dann ansehen, fehlen die Lehrzeichen und auch die \\ ... So kann ich natürlich nicht die passende Datei finden, die ich meinem Script übergebe. Also wenn ich so ein Namen an mein Script übergebe:

Code: Alles auswählen

sh mein_script.sh /pfad/zu meiner/Datei mit Lehrzeichen.avi

und mir dann die Variable $1 an schaue in meinem Script, fehlen einfach die Lehrzeichen. Kann man das umgehen? Weil brauche ja schon den richtigen Pfad.

[detix]

...dessen Pfad und auch Dateiname, Lehrzeichen enthält.

Nur zum Verständnis, was bitte sind Lehrzeichen?

[The Hit-Man]

spaces

[uname]

Versuche Anführungszeichen.

[Radfahrer]

Nur zum Verständnis, was bitte sind Lehrzeichen?

Das sind schlaue Zeichen, von denen man etwas lernen kann.

[Cae]

Code: Alles auswählen

sh mein_script.sh /pfad/zu meiner/Datei mit Lehrzeichen.avi

Entweder in Ticks/Anfuehrungszeichen packen:

Code: Alles auswählen

$ sh mein_script.sh '/pfad/zu meiner/Datei mit Lehrzeichen.avi'
$ sh mein_script.sh "/pfad/zu meiner/Datei mit Lehrzeichen.avi"

oder, wenn der Benutzer das nicht extra eingeben soll, kann man auch read nehmen:

Code: Alles auswählen

#!/bin/sh

read -p 'enter filename ' arg1 # anstatt arg1="$1"

rm -f "$arg1" # mehr oder weniger sinnvolle Aktion

Dann wird nach dem Starten interaktiv der Dateiname abgefragt, der an dieser Stelle nicht durch die Shell in Unterausdruecke aufgeteilt oder sonstwie zerfleischt wird. Und man koennte immer noch per echo 'foo bar' | dein-script "auf der Kommandozeile" den Parameter uebergeben.

Gruss Cae

[rendegast]

Auch geht Backslash-Escapen

Code: Alles auswählen

./script.sh der\ pfad/der\ datei\ name

(erreicht zBsp. durch path-completion)
Sieht aber schlimm aus.

[Meillo]

[...] oder, wenn der Benutzer das nicht extra eingeben soll, kann man auch read nehmen:

Code: Alles auswählen

#!/bin/sh

read -p 'enter filename ' arg1 # anstatt arg1="$1"

rm -f "$arg1" # mehr oder weniger sinnvolle Aktion

Dann wird nach dem Starten interaktiv der Dateiname abgefragt, [...]

Nein! Bitte so einen Mist gleich gar nicht anfangen! Das widerspricht dem (guten!) Kommandozeileninterface-Stil von Unix. Schreibe deine Programme im gleichen Stil wie die anderen Programme sind: Dateinamen werden als Kommandozeilenargumente uebergeben. Wenn deine Dateinamen Whitespaces enthalten -- was sie nicht sollten -- dann musst du halt geeignet Quoten.

[Cae]

[...] oder, wenn der Benutzer das nicht extra eingeben soll, kann man auch read nehmen:

Code: Alles auswählen

#!/bin/sh

read -p 'enter filename ' arg1 # anstatt arg1="$1"

rm -f "$arg1" # mehr oder weniger sinnvolle Aktion

Dann wird nach dem Starten interaktiv der Dateiname abgefragt, [...]

Nein! Bitte so einen Mist gleich gar nicht anfangen!

Okay, ich geb' ja zu, dass das fuer den Grossteil der Anwendungen ungeeignet ist und die Usability kaputt macht. Aber willst du wirklich einen String wie f""oo'bar"b''az haendisch escapen [1]? Also wird man ein Tool nehmen/bauen, was einem das Escaping abnimmt -- welches dann sinnvollerweise aus einer Datei bzw. stdin befuellt wird, um besagtes Escaping nicht zu haben. Oder? Dann kann man's auch gleich im Programm selbst machen.

Falls es da vernuenftige Alternativen gibt, immer her damit. Ich empfinde meinen Vorschlag von oben als Kruecke, weil ich nix besseres kenne. Die Loesung

Wenn deine Dateinamen Whitespaces enthalten -- was sie nicht sollten

(Hervorhebung von mir) -- ist natuerlich auch ein Weg, solange man sich die Pfade bzw. Eingangsdaten aussuchen kann.

Gruss Cae

[1] waere dann z.B. 'f""oo'\''bar"b'"''"az

[Phineas]

Wenn es wirklich hart zu escapen wird, nehme ich read + printf:

Code: Alles auswählen

~> echo $(read -er s && printf %q "$s")
f""oo' bar"b''az
f\"\"oo\'\ bar\"b\'\'az
~>

Das "echo" kann natürlich auch ein Script sein.
Bei führenden/schließenden Whitespaces und bei Newlines muss die Konstruktion aber auch passen.
Ich benutze die Bash.

[Meillo]

Aber willst du wirklich einen String wie f""oo'bar"b''az haendisch escapen [1]?

Wer solche Dateinamen auf seinem System hat, soll sich zurecht damit rumschalgen muessen, sonst fangen die Leute noch an das zur Normalitaet werden zu lassen. Mit den Spaces ist es schon jetzt eine Qual. Wenn man in dieser Hinsicht anfaengt das System anzupassen, nur weil die Nutzer meinen sie brauchen das, dann fuehrt der Weg unweigerlich zu den Inkonsistenzen die man von Windows kennt. Ein klares, einheitliches System erhaelt man nur wenn man die klaren Konzepte hart durchsetzt. Haetten das die Jungs in den Bell Labs damals nicht getan, dann waere Unix heute nicht das was es ist. Und dennoch gab es auch da genug zu bekaempfen, wenn man an die Unix Wars denkt. Wenn man sich heute die unschoenen Stellen anschaut (z.B. Sockets) dann sind das eben genau die Folgen von scheinbar praktischen aber inkonsistenten Erweiterungen. In Plan 9 sieht man wie man es besser macht.

[Phineas]

Aus meiner Musiksammlung:

Code: Alles auswählen

01 - Rock 'n' Roll Gypsy (Rock 'n' Roll Outlaw).mp3

Sollte ich mich wirklich in die Steinzeit zurück begeben und so etwas ändern? Warum sind auf Linux-Dateisystemen denn alle Zeichen außer Slash und Nullbyte erlaubt?

Man gewöhnt sich an solche Dateinamen und mit der Zeit hat man immer weniger Ärger damit.

[Meillo]

Aus meiner Musiksammlung:

Code: Alles auswählen

01 - Rock 'n' Roll Gypsy (Rock 'n' Roll Outlaw).mp3

Sollte ich mich wirklich in die Steinzeit zurück begeben und so etwas ändern?

Es ist halt eine Frage der Praeferenz was man hoeher wertet: Die Konsistenz und Eleganz eines Systems oder die Moeglichkeit moeglichst viele und exakte Informationen in Dateinamen zu packen. Mir ist ersteres sehr wichtig. Bei zweiterem glaube ich, dass es der falsche Ansatz ist um das Problem zu loesen. Es gibt viel mehr sinnvolle Metadaten als man in einen Dateinamen packen kann und sollte. Wir brauchen deshalb keine laengeren Dateinamen mit noch mehr Sonderzeichen und am besten Unterformate, sondern die Moeglichkeit Metadaten sinnvoll abzulegen. Der Name einer Datei soll sie genausowenig beschreiben wie ihre Dateiendung. ... Aber das ist halt die Diskrepanz zwischen Soll und Ist.

Warum sind auf Linux-Dateisystemen denn alle Zeichen außer Slash und Nullbyte erlaubt?

Das war IMO ein Fehler. Zumindest das Newline-Zeichen haette man zusaetzlich verbieten sollten.

Man gewöhnt sich an solche Dateinamen und mit der Zeit hat man immer weniger Ärger damit.

Das ist IMO gerade nicht der Fall. Man hat nur scheinbar keinen Aerger damit. Anfangs mag es vielleicht auch geschickt sein, aber langfristig bricht jedes System auseinandern, das nicht konsequent wenigen klaren Konzepten folgt.

[hikaru]

Aus meiner Musiksammlung:

Code: Alles auswählen

01 - Rock 'n' Roll Gypsy (Rock 'n' Roll Outlaw).mp3

Sollte ich mich wirklich in die Steinzeit zurück begeben und so etwas ändern?

Bei mir hieße die Datei so:

Code: Alles auswählen

01_-_Helen_Schneider_-_Rock_n_Roll_Gypsy_Rock_n_Roll_Outlaw.mp3

Das Fehlen der Ticks und Klammern tut dem Informationsgehalt nicht wirklich weh.

Es gibt viel mehr sinnvolle Metadaten als man in einen Dateinamen packen kann und sollte. Wir brauchen deshalb keine laengeren Dateinamen mit noch mehr Sonderzeichen und am besten Unterformate, sondern die Moeglichkeit Metadaten sinnvoll abzulegen. Der Name einer Datei soll sie genausowenig beschreiben wie ihre Dateiendung.

Konsequent zuende gedacht landet man an dem Punkt wo der Dateiname der MD5-Summe (oder SHA1-Summe oder was auch immer) der Datei gleich ist.

Mir ist das dann doch etwas zu radikal. Ein gewisser Grundstock an menschenlesbaren Infos sollte da schon drin stecken. Das Problem von Metadaten ist nämlich, dass es dafür kein einheitliches Format gibt. Ein id3-Tag* sieht anders aus als ein Vorbis-Comment oder das Matroska-EBML. Ganz zu schweigen von irgendwelchen völlig anderen Dateitypen mit völlig anderen Metainformationen wie L/OO-Dokumenten oder Plain-Text-Dateien die sowas gar nicht haben.
Im Grunde bräuchte man einheitlich für alle Dateitypen eine Art MIME- oder Magic-Information, die allerdings Aussagen über den Inhalt trifft. Ich weiß nicht ob DB-basierte Dateisysteme wie zfs sowas leisten können. Die Anwenderprogramme (allen voran Dateimanager, aber auch Shells) müssten dann konsequent über diese Informationen Zugriff auf die Dateien bieten.


*) Man werfe zum Ermitteln der Version eine Münze.

[Meillo]

Es gibt viel mehr sinnvolle Metadaten als man in einen Dateinamen packen kann und sollte. Wir brauchen deshalb keine laengeren Dateinamen mit noch mehr Sonderzeichen und am besten Unterformate, sondern die Moeglichkeit Metadaten sinnvoll abzulegen. Der Name einer Datei soll sie genausowenig beschreiben wie ihre Dateiendung.

Konsequent zuende gedacht landet man an dem Punkt wo der Dateiname der MD5-Summe (oder SHA1-Summe oder was auch immer) der Datei gleich ist.

Mir ist das dann doch etwas zu radikal. Ein gewisser Grundstock an menschenlesbaren Infos sollte da schon drin stecken.

Bei heutigen Dateisystemen, ja.

Das Problem von Metadaten ist nämlich, dass es dafür kein einheitliches Format gibt. Ein id3-Tag* sieht anders aus als ein Vorbis-Comment oder das Matroska-EBML. Ganz zu schweigen von irgendwelchen völlig anderen Dateitypen mit völlig anderen Metainformationen wie L/OO-Dokumenten oder Plain-Text-Dateien die sowas gar nicht haben.

Das allerdings meinte ich nicht. Ich glaube, dass es ein Fehler ist, die inhaltlichen (vielleicht auch die technischen) Metadaten im jeweiligen Dateiformat abzulegen. Entweder man packt die Nutzdaten in generische Container, wie beispielsweise bei Emails mit MIME. Oder man legt die Metadaten separat ab und verknuepft die (versionierten!) Nutzdaten ueber Hashwerte. Das ist dann wie bei der freedb. Oder so aehnlich wie bei Unix-Dateisystemen mit den Inodes und Daten-Nodes.


So oder so, ich bleibe dabei, dass Dateinamen gerne ein menschenlesbarere, aussagekraeftiger Identifier sein duerfen, aber keinen Metadatensatz transportieren sollten, jedenfalls nicht in den heutigen Systemen, die nicht dafuer gemacht wurden. (Erinnert euch daran, dass frueher bei Unix-Dateisystemen die Dateinamen auf 14 Zeichen begrenzt waren!)

[Phineas]

Ich behaupte natürlich nicht, dass ihr im Unrecht seid. Ich für meinen Teil, erspare mir aber die Umbenennungsorgien schon sehr lange und komme prima damit klar.

[hikaru]

Die Umbenennungsorgien lassen sich doch automatisieren.

[wanne]

Wenn das ganze mal in ner Variable drin ist die shell da schlau genug:
Alos sowas funktioniert z.b. einwandfrei:

Code: Alles auswählen

$ cat ./arg
echo "$1"
$ cat ./auf
sh ./arg "$1"
$ sh ./auf 0x20:\ \"\ \"
0x20: " "

Lediglich beim eingeben wird interpretiert. Und da erledigt das mit dem escaen hoffentlich die Autovervollständigung.
Ich habe mir vor kurzem mal die Zähne ausgebrochen, weil ich gedacht habe, dass das ein sicherheitsloch ist, dass der dhclient da einfach ungefiltert eingehenden Netzwerktrafic in eine Variable füllt und die dann als root mit echo ausgibt. Aber mir ist es nicht gelungen da irgend wie code reinzubekommen, der dann ausgeführt wird.
Das sieht da so aus:

Code: Alles auswählen

echo nameserver $nameserver >>$new_resolv_conf

Wobei $nameserver von einem angreifer beliebig gewählt werden kann.