Datei mit 'üblem' Dateinamen skriptgesteuert kopieren

[GregorS]

Hallihallo!

Ich schreibe gerade ein Skriptchen, das zwei Verzeichnisse synchronisieren soll. Da ich keinerlei Einschränkungen hinnehmen möchte (z.B. "Dateien mit Leerzeichen oder Umlauten im Namen sind tabu"), suche ich nach einer Möglichkeit, Dateien mit Sonder- oder Leerzeichen im Namen *aus einem Skript heraus* zu kopieren.

In Form eines direkt eingegebenen Shellbefehls bekomme ich das hin, dieselbe (wirklich dieselbe, ich hab's dutzende Male probiert und schon eine Hornhaut auf der Brille) Syntax scheitert im Skript jedoch an Fehlermeldungen von 'stat', das wohl von cp aufgerufen wird.

Bin ich doof? Habe ich Tomaten auf den Augen?

Jede Hilfe wird dankbar entgegengenommen!

Gregor

[schorsch_76]

Morgen und noch frohe Weihnachten!

Quote die dateinamen in "" . Bsp.

mv "mein name mit leerzeichen und äöü" "/home/xxx/meine sachen mit leer/."

Gruß

schorsch

[GregorS]

Hallo Schorsch,

erstmal Danke für die Antwort. Aber leider funktioniert das eben nicht. Als direkt in die Shell eingetippter oder kopierter Befehl tut das klaglos. Sobald ich etwas derartiges im Skript machen möchte, bekomme ich z.B.

Code: Alles auswählen

Befehl ist "cp -ar "/home/xxx/dokumente/sync/dokumente/shellskript/gss/test1/./datei mit leerzeichen.txt" /home/xxx/dokumente/sync/dokumente/shellskript/gss/test2/"
cp: Aufruf von stat für „"/home/xxx/dokumente/sync/dokumente/shellskript/gss/test1/./datei“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „mit“ nicht möglich: Datei oder Verzeichnis nicht gefunden
cp: Aufruf von stat für „leerzeichen.txt"“ nicht möglich: Datei oder Verzeichnis nicht gefunden
 

Die erste Zeile ist die Ausgabe des Befehls per echo.
Wie zu erkennen ist, wird, wenn cp stat aufruft, die Angabe der Quelldatei wieder so behandelt, als wären die Anführungszeichen nicht da.

Als möglichen Workaround habe ich schon darüber nachgedacht, Dateien mit Leerzeichen vorübergehend in welche ohne Leerzeichen umzubenennen. Aber das würde dann eben nur für Leerzeichen etwas bringen und nicht pauschal für alle anderen Sonderzeichen auch.

Gruß

Gregor

[123456]

da scheinen zu viele Hochzeichen zu sein. Aber poste doch mal das Skript - sonst wird man schwer einen Fehler finden.

[michaels]

Hm, was soll denn das sein:

/./

?

Aus dem stat Aufruf sieht es fast so aus, das der Punkt das Problem ist. Soll die Datei versteckt sein? Warum dann der Slash!?

Gruß

[GregorS]

Hallo Michael,

die "äußeren" Hochkommas sind die, die ich im echo-Befehl angegeben habe. Die um den Quellpfad werden beim Zusammenbau von Variablen im Skript erzeugt. Auch das "/./" ist noch so ein Überbleibsel, die Variable, die den Dateinamen enthält, beginnt mit "./" und zusammen mit dem Pfad zum Quellverzeichnis wird dann eben "/./" draus. Das dürfte aber keinesfalls die Ursache für das Problem sein, denn der "." in einem Verzeichnis steht ja für das Verzeichnis selbst.

Ich werde sehen, dass ich ein Skriptchen poste, das die Problematik verdeutlicht. Den aktuellen Stand meines Sync-Skriptchens möchte ich hier lieber nicht loslassen, denn das hat mittlerweile einige Zeilen.

Gruß

Gregor

[GregorS]

Aus dem stat Aufruf sieht es fast so aus, das der Punkt das Problem ist. Soll die Datei versteckt sein? Warum dann der Slash!?

Woran meinst Du erkennen zu können, dass der Punkt das Problem sei?

Gruß

Gregor

[GregorS]

Hallo,

da ich exzessiv Variablen verwendet habe, lässt sich mein Skriptchen schlecht kürzen oder nur auszugsweise posten. Ich habe es daher unter

http://nopaste.debianforum.de/33809

abgelegt. Die problematischen Zeilen befinden sich ziemlich nah am unteren Ende, so ca. bei Zeile 335. Zu erkennen ist der Teil, an dem ich gerade hänge, an zwei Rauten (#), die sich jeweils am Zeilenanfang befinden.

Gruß

Gregor

[GregorS]

da scheinen zu viele Hochzeichen zu sein. Aber poste doch mal das Skript - sonst wird man schwer einen Fehler finden.

Auch wenn’s Dir vielleicht anders scheint, die Zahl der Hochkommas stimmt perfekt. Vielleicht übersiehst Du, dass sich die erste Zeile der Ausgabe über zwei Zeilen des "Code"-Zitats erstreckt. Das Skriptchen habe ich mittlerweile in den nopaste-Berfeich gestellt - s. anderes Posting.

Gruß

Gregor

[chrisbra]

Auch wenn’s Dir vielleicht anders scheint, die Zahl der Hochkommas stimmt perfekt. Vielleicht übersiehst Du, dass sich die erste Zeile der Ausgabe über zwei Zeilen des "Code"-Zitats erstreckt. Das Skriptchen habe ich mittlerweile in den nopaste-Berfeich gestellt - s. anderes Posting.

Da sind mehrere Hochkommas drin? Das könnte ein Problem sein. Aber ehrlich gesagt, mir fehlt die Lust, mich durch hundert Zeilen Code zu lesen.

Teste halt mal mit set -x oder bring ein einfaches Minimalbeispiel.

[uname]

Einen Fehler erkenne ich so nicht. Aber auf jeden Fall werden die Anführungszeichen nicht beachtet, wodurch die oben stehenden Fehlermeldungen entstehen.

Nutze doch statt "cp" mal "rsync". Wie sieht das Ergebnis dann aus? Auch solltest du die Anführungszeichen vielleicht im Script nicht um die Variable, sondern bereits in der Variablen einbauen. Vielleicht liegt es daran.

[gms]

http://nopaste.debianforum.de/33809

hätte mir das gerne angeguckt, bekomme aber selbst nach dem Download nur ein paar Leerzeichen und Zeilenumbrüche zu sehen:

Code: Alles auswählen

gms@gms1 ~/tmp/download $ hexdump 33809.txt
0000000 200a 2020 0a20
0000006

Hast du da was falsches gepostet, oder wurde das vom Forum "zensuriert", oder bin ich der einzige mit dem Problem ?

Gruß
gms

[TRex]

Wurde auf Bitte des Autors wieder entfernt.

[GregorS]

Nochmals hallo!

Danke für Eure Antworten.

Das Problem besteht immer noch, allerdings hat mich ein Freund auf die Idee gebracht, dass sich Login-Shell und die im Skript Verwendete evtl. unterscheiden. Das könnte erklären, warum der Befehl als direkt eingegebener Shell-Befehl funktioniert, nicht aber im Skript. Ich werde das Problem einfach mal etwas ruhen lassen. Hin und wieder bringt ja der zeitliche Abstand eine Lösung.

Gruß

Gregor

[GregorS]

... set -x ... .

Wo ist das dokumentiert? 'man set' und 'apropos set' ergaben keine hilfreichen Hinweise.

Gruß

Gregor

[gms]

Wo ist das dokumentiert? 'man set' und 'apropos set' ergaben keine hilfreichen Hinweise.

-x The shell shall write to standard error a trace for each command after it expands the command and
before it executes it. It is unspecified whether the command that turns tracing off is traced.

findest du aber auch z.B unter "man bash" beschrieben

Gruß
gms

[GregorS]

-x The shell shall write to standard error a trace for each command after it expands the command and
before it executes it. It is unspecified whether the command that turns tracing off is traced.

findest du aber auch z.B unter "man bash" beschrieben

Hm. 'man set' ergibt bei mir

No manual entry for set

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.

Gruß

Gregor

[gms]

Hm. 'man set' ergibt bei mir

No manual entry for set

'manpages-posix' nicht installiert ?

Und ob 'man bash' verlässliche Informationen ergibt, steht in den Sternen.

alle Manpages werden von Menschen gewartet und sind daher potentiell fehlerbehaftet

Verlässlich ist (wahrscheinlich) nur, was man selbst programmiert hat.

naja, dein Script dürfte auch nicht fehlerfrei sein

Warum hast du das eigentlich entfernen lassen?

Gruß
gms

[chrisbra]

... set -x ... .

Wo ist das dokumentiert? 'man set' und 'apropos set' ergaben keine hilfreichen Hinweise.

man bash

[GregorS]

'manpages-posix' nicht installiert ?

Nein, hatte ich tatsächlich nicht. Ich finde, sowas sollte Teil des Grundsystems sein. Zumindest, wenn Programme installiert werden, deren Doku dort zu finden ist. Ich kann mich nicht erinnern, das weggeklickt zu haben (hätte ich sicherlich auch nicht, denn Platz ist selten ein Problem).

naja, dein Script dürfte auch nicht fehlerfrei sein

Na, deshalb hatte ich ja hier gefragt

Warum hast du das eigentlich entfernen lassen?

Obwohl es das, was es soll, noch nicht kann, ist es schon über 300 Zeilen lang. Im Gegensatz zu einem Freund, der Programme vom Kern her zu schreiben beginnt, fange ich (zumindest derzeit) immer damit an, dass ich das "Gerüst" außenrum baue. Mit Gerüst meine ich z.B. das Parsen der Befehlszeile oder das, was bei Angabe von '-h' erscheint.
Ebenso schreibe ich meistens vor der ersten echten Codezeile schonmal, was ich vorhabe. Daraus entstehen dann die Kommentare im Quellcode.

Gruß

Gregor

[gms]

Warum hast du das eigentlich entfernen lassen?

Obwohl es das, was es soll, noch nicht kann, ist es schon über 300 Zeilen lang. Im Gegensatz zu einem Freund, der Programme vom Kern her zu schreiben beginnt, fange ich (zumindest derzeit) immer damit an, dass ich das "Gerüst" außenrum baue. Mit Gerüst meine ich z.B. das Parsen der Befehlszeile oder das, was bei Angabe von '-h' erscheint.
Ebenso schreibe ich meistens vor der ersten echten Codezeile schonmal, was ich vorhabe. Daraus entstehen dann die Kommentare im Quellcode.

das ist ja auch gut so ...
Dein Script habe ich ja leider nicht gesehen, aber Shellscripte lassen sich sehr leicht über "Shell Function Definitions" ( siehe man bash ) modularisieren. Wenn sich diese Funktionen dann vielleicht sogar auch in anderen Scripten nutzen lassen, können diese auch in eigene Dateien ausgelagert werden, die dann von dem jeweiligen Script "gesourced" werden ( siehe man "source filename [arguments]" )

Aber selbst wenn das Script 300 Zeilen umfaßt, ist mir der Grund für das Entfernen schleierhaft

Gruß
gms

[GregorS]

Und ob 'man bash' verlässliche Informationen ergibt, steht in den Sternen.

alle Manpages werden von Menschen gewartet und sind daher potentiell fehlerbehaftet

Es ging nicht um Fehler. Über sowas rege ich mich selten auf.

Echt blöd finde ich aber, wenn es bei einem so wichtigen und zentralen Tool wie einer weit verbreiteten Shell Änderungen gibt, die neuere Versionen inkompatibel machen. Das kann man ja nun wirklich vermeiden.

Gruß

Gregor

[GregorS]

(...) Grund für das Entfernen schleierhaft

Mach' Dir nix draus. Ich weiß auch nicht alles, was ich gerne wüsste

Gruß

Gregor

[gms]

Echt blöd finde ich aber, wenn es bei einem so wichtigen und zentralen Tool wie einer weit verbreiteten Shell Änderungen gibt, die neuere Versionen inkompatibel machen.

diese Änderung macht die Shell dafür kompatibler zu anderen Shells. Womit wir bei der Frage wären: welche Kompatibilität zählt mehr, die zu einem undokumentierten "Feature" ( eher Fehler ) einer Vorversion, meiner Meinung nach nicht.

[gms]

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