Datei mit 'üblem' Dateinamen skriptgesteuert kopieren

[GregorS]

Ich weiß auch nicht alles, was ich gerne wüsste

Ah, verstehe, das war der Grund, du möchtest ja das Problem mit deinen 'üblen' Dateinamen ruhen lassen

Nein, falsch geraten. Wenn Du PNs zulassen würdest, wärst Du schon schlauer

Gruß

Gregor

[gms]

Nein, falsch geraten. Wenn Du PNs zulassen würdest, wärst Du schon schlauer

oops, die hatte ich vergessen wieder einzuschalten, danke für den Hinweis
aber bitte schicke mir jetzt nicht dein Script, ich habe ansich nichts dagegen, wenn mich wer über PN kontaktiert, allerdings nur wenn es um Dinge geht, die im Forum selber nichts verloren haben ( z.B persönliche Fragen/Antworten, oder Fragen zu "ganz anderen Distributionen", wie z.B Gentoo... )

Gruß
gms

[GregorS]

Hallo,

unter

http://nopaste.debianforum.de/34028

gibt es jetzt ein kleines Test-Skriptchen, mit dem mein Problem nachvollzogen werden kann. Zumindest zeigt es bei mir den exakt gleichen Fehler. Wenn ich den Befehl per Copy&Paste&Enter ausführe, funktioniert’s einwandfrei.

Was nu’?

Gruß

Gregor

[gms]

Code: Alles auswählen

befehl="cp -ar src/\"blöder dateiname\" dst"

# zeigen
echo "$befehl"
echo "---------------------------------------"

# und ausführen
eval "$befehl"

wenn du Kommandos zusammen-stoppelst in eine Variable, müssen die Argumente dieses Kommandos nachträglich von der Shell wieder richtig zerteilt werden ( "word splitting" nennt sich das, wenn ichs richtig im Kopf habe ), das kannst du über das 'eval' Kommando erledigen lassen.
Beim echo habe ich noch die Quotes hinzugefügt, damit das Kommando korrekt angezeigt wird

Gruß
gms

[GregorS]

Hallo gms,

tausend Dank, das war’s anscheinend!

Wo zur Hölle hätte ich das selbst herausfinden können? Muss ich gar doch mal 'man bash' ausdrucken und lesen?

Gruß

Gregor

[rendegast]

Was gibt

Code: Alles auswählen

file -e soft Dein_Skript

Paßt das zur Lokalisierung Deiner Shell?

Code: Alles auswählen

locale

Ich versuche Skripte ohne Umlaute etc. zu erstellen,
obiges Kommando gibt dann "... ASCII text ..." oder "... 8859-1 ..." aus.

Du kannst solche Probleme mit Konstrukten wie zBsp.

Code: Alles auswählen

find Verzeichnis -exec cp {} \;

umgehen.




Addon zur Verwendung von '#!/bin/bash'.
Auf debian bis lenny ist '#!/bin/sh' normalerweise eine Verlinkung auf /bin/bash,
die dann aber doch im Zweifel Nicht-POSIX-Funktionen zuläßt.
Ab squeeze wird mittlerweile standardmäßig dash als /bin/sh-Alternative verwendet,
die streng POSIX-kompatibel ist.
Das kann bei früher funktionierenden "Pseudo-POSIX"-Skripten Fehler produzieren.
Diese Skripte sind dann auf '#!/bin/bash' umzustellen, oder auf POSIX durchzusehen.

[GregorS]

Hallo Rendegast,

das Problem wurde inzwischen beseitigt.

Ursache war das, was gms in seinem Posting als "word splitting" bezeichnet hat. Die Lösung bestand in der Verwendung von "eval".

Gruß

Gregor

[chrisbra]

Und ob 'man bash' verlässliche Informationen ergibt, steht in den Sternen. In einem anderen Thread musste ich erfahren, dass es bei der Bash mal inkompatible Änderungen gab. Wenn man das extrapoliert, ergibt sich: Verlässlich ist (wahrscheinlich) nur, was man selbst programmiert hat.

Wer sprach davon, dass es nicht dokumentier wäre? Es ist in man bash dokumentiert und es gibt sogar eine Einstellung, wie man das andere Verhalten wieder einstellen kann:

Code: Alles auswählen

chrisbra@256bit:~/torrent$ man bash |grep -A3 'compat31'
              compat31
                      If set, bash changes its behavior to that of version 3.1
                      with respect to quoted arguments to the conditional com‐
                      mand’s =~ operator.
chrisbra@256bit:~/torrent$

[chrisbra]

Code: Alles auswählen

befehl="cp -ar src/\"blöder dateiname\" dst"

# zeigen
echo "$befehl"
echo "---------------------------------------"

# und ausführen
eval "$befehl"

wenn du Kommandos zusammen-stoppelst in eine Variable, müssen die Argumente dieses Kommandos nachträglich von der Shell wieder richtig zerteilt werden ( "word splitting" nennt sich das, wenn ichs richtig im Kopf habe ), das kannst du über das 'eval' Kommando erledigen lassen.
Beim echo habe ich noch die Quotes hinzugefügt, damit das Kommando korrekt angezeigt wird

Man möchte eigentlich keine kompletten Befehle in einer Variablen speichern. Das riecht nach Ärger und provoziert Fehler.
Und eval sollte man nie, gar nicht machen. http://mywiki.wooledge.org/BashFAQ/050

Code: Alles auswählen

chrisbra t41:/tmp/bash [1162]% mkdir src target
chrisbra t41:/tmp/bash [1163:2]% cd src
chrisbra t41:/tmp/bash/src [1164]% touch a b c d ' b"; rm -rf *;"'
chrisbra t41:/tmp/bash/src$ for i in *; do befehl="cp -ar \"$i\" ../target"; echo "$befehl"; eval "$befehl"; done
cp -ar "a" ../target
cp -ar "b" ../target
cp -ar " b"; rm -rf *;"" ../target
cp: Fehlender Zieldatei‐Operand hinter „ b“
„cp --help“ gibt weitere Informationen.
„a“ entfernt
„b“ entfernt
„ b"; rm -rf *;"“ entfernt
„c“ entfernt
„d“ entfernt
bash: : Kommando nicht gefunden.
cp -ar "c" ../target
cp: Aufruf von stat für „c“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp -ar "d" ../target
cp: Aufruf von stat für „d“ nicht möglich: Datei oder Verzeichnis nicht gefunden
chrisbra t41:/tmp/bash/src$ ls
chrisbra t41:/tmp/bash/src$ ls ../target
a b
chrisbra t41:/tmp/bash/src$

Und jetzt hättest Du verloren.

Also nie, niemals eval mit unbekannten Daten füttern. Das Resultat könnte fatal sein.

[gms]

Wer sprach davon, dass es nicht dokumentier wäre?

vermutlich beziehst du dich auf meinen Beitrag

Es ist in man bash dokumentiert und es gibt sogar eine Einstellung, wie man das andere Verhalten wieder einstellen kann:

Code: Alles auswählen

chrisbra@256bit:~/torrent$ man bash |grep -A3 'compat31'
              compat31
                      If set, bash changes its behavior to that of version 3.1
                      with respect to quoted arguments to the conditional com‐
                      mand’s =~ operator.
chrisbra@256bit:~/torrent$

anscheinend doch nicht, oder du hast da was falsch verstanden

Gruß
gms

[chrisbra]

Wer sprach davon, dass es nicht dokumentier wäre?

vermutlich beziehst du dich auf meinen Beitrag

Nein, ich bezog mich auf Gregor, der sowas schrieb:

Und ob 'man bash' verlässliche Informationen ergibt, steht in den Sternen. In einem anderen Thread musste ich erfahren, dass es bei der Bash mal inkompatible Änderungen gab. Wenn man das extrapoliert, ergibt sich: Verlässlich ist (wahrscheinlich) nur, was man selbst programmiert hat.

Mift, da ist mir wohl ein Quotinglevel abhanden gekommen.

[gms]

Nein, ich bezog mich auf Gregor, der sowas schrieb:

Und ob 'man bash' verlässliche Informationen ergibt, steht in den Sternen. In einem anderen Thread musste ich erfahren, dass es bei der Bash mal inkompatible Änderungen gab. Wenn man das extrapoliert, ergibt sich: Verlässlich ist (wahrscheinlich) nur, was man selbst programmiert hat.

ja aber in der 3.1 war das Quoting tatsächlich unzureichend dokumentiert, deshalb ist ja überhaupt diese ungute Situation mit der Inkompatibilität und der nachträglichen Implementierung von "compat31" entstanden
Mit solchen Problemen hat aber jedes größere Software-Projekt zu kämpfen, die Dokumentation hinkt meistens hinterher.

[GregorS]

Hallo!

Was ich da über die (Nicht-) Verwendung von eval lese, erheitert mich nicht sonderlich. Allerdings ist das, soweit ich es verstanden habe, nur dann problematisch, wenn auch Leute Zugriff auf die gehändelten Daten haben, denen ich nicht vertrauen kann und die darüber hinaus Böses im Sinn haben. Da ich mein Sync-Skriptchen nur für mich selbst schreibe und ich der Einzige bin, der auf die betreffenden Daten/Verzeichnisse Zugriff hat, sehe ich kein Problem. Ich muss nur daran denken, deutlich auf die möglichen Probleme in Doku (und Skript) hinzuweisen - für den Fall, dass doch mal eine andere Person mein Skript verwenden möchte.

Übrigens: Mit der Bemerkung, es stehe in den Sternen, ob 'man bash' verlässliche Informationen ergibt, meinte ich nicht, dass das Problem nicht dokumentiert sei, sondern dass ich mich anscheinend nicht darauf verlassen kann, dass 'man bash' auf Rechner A dasselbe ergibt wie 'man bash' auf Rechner B (bezüglich derselben Funktion).

Grüße

Gregor

[chrisbra]

ja aber in der 3.1 war das Quoting tatsächlich unzureichend dokumentiert, deshalb ist ja überhaupt diese ungute Situation mit der Inkompatibilität und der nachträglichen Implementierung von "compat31" entstanden
Mit solchen Problemen hat aber jedes größere Software-Projekt zu kämpfen, die Dokumentation hinkt meistens hinterher.

Mag sein. Ich versuche immer, portabel zu arbeiten. Und daher vermeide ich bash-spezifische Lösungen. Zumal =~ mir in bash ziemlich fragil vorkam, die paar Mal, wo ich es getestet habe.