2013-12-11 11 views
13

Ich versuche, eine Datei mit Shell-Skriptbefehl zu komprimieren. Ich benutze folgenden Befehl:Zip-Befehl funktioniert nicht

wobei $ Dateien alle Eingabedateien enthalten. Aber ich bin immer eine Warnung wie folgt

zip warning: name not matched: myfile.dat 

und noch eine Sache, die ich beobachtet, dass die Datei, die zuletzt in der Liste der Dateien in einem Ordner ist die obige Warnung und diese Datei nicht gezippt zu werden.

Kann mir jemand erklären, warum das passiert? Ich bin neu in der Shell-Script-Welt.

+3

Können Sie ein 'ls -ltr' für' myfile.dat' bereitstellen? Ich habe von einigen Problemen mit Dateien gehört, die zu groß sind und/oder symbolische Links sind. – eebbesen

Antwort

9

zip Warnung: Name nicht abgestimmt: myfile.dat

Das bedeutet, die Datei myfile.dat existiert nicht.

Sie erhalten denselben Fehler, wenn die Datei ein Symlink ist, der auf eine nicht vorhandene Datei verweist.

Wie Sie sagen, was auch immer die letzte Datei von $FILES ist, wird es nicht zusammen mit der Warnung zum Zip hinzugefügt. Also ich denke, etwas stimmt nicht mit der Art, wie Sie $FILES erstellen. Wahrscheinlich gibt es am Ende des letzten Dateinamens eine Zeilenumbrüche, Zeilenumbrüche, Leerzeichen, Tabulatoren oder andere unsichtbare Zeichen, die zu etwas führen, das nicht existiert. Versuchen Sie dies zum Beispiel:

for f in $FILES; do echo :$f:; done 

Ich wette, die letzte Zeile nicht korrekt sein wird, zum Beispiel:

:myfile.dat : 

... oder so ähnlich statt :myfile.dat: ohne Zeichen vor den letzten :

UPDATE

Wenn Sie sagen, begann das Skript nach runn arbeiten dos2unix darauf, das bestätigt, was alle schon vermutet haben, dass es irgendwie eine Wagenrückgabe am Ende Ihrer $FILES Liste gab.

od -c zeigt die Wagenrücklauf. Versuchen echo $FILES | od -c

+0

Aber ich bin Bale, um diese Datei in dem angegebenen Ordner zu sehen –

+0

Wie gesagt, was immer die letzte Datei in der Liste ist, hat diesen Fehler. Wenn ich versuche, die Datei type.txt zusammen mit der Datei $ FILES zu komprimieren, dann hat type.txt diese Warnung und wird nicht in zip eingeschlossen! –

+3

Dann brauchen wir mehr Details. Was ist in $ Dateien? Zeige ein ls wie gewünscht. Das folgende "funktioniert für mich": '$ mkdir ziptest $ cd ziptest $ touch abc $ mkdir d $ touch d/e $ zip foo.zip abcd/e Zugabe: eine (gespeichert 0%) Hinzufügen : b (gespeichert 0%) hinzufügen: c (gespeichert 0%) hinzufügen: d/e (gespeichert 0%) ' –

0

Ich konvertierte mein Skript für Unix-Umgebung mit dos2unix Befehl und führte mein Skript als ./myscript.sh stattdessen bash myscript.sh.

+0

Sowohl './Myscript.sh' und' bash myscript.sh' sollten funktionieren.Wenn Sie sagen, dass das Skript nach der Ausführung von 'dos2unix' funktioniert, bestätigt das, was alle schon vermutet haben, dass es am Ende Ihrer' $ FILES'-Liste irgendwie eine Wagenrückgabe gegeben hat. – janos

+0

@janos Du hast Recht, es gab einen Wagenrücklauf. Aber es gibt immer noch ein Problem, wenn ich das Skript mit 'bash myscript.sh' ausführe. Aber mit ./myscript.sh läuft mein Skript einwandfrei! –

0

Leerzeichen sind nicht erlaubt:

es würde scheitern, wenn es mehr als eine Datei (en) in $ FILES sind, wenn Sie sie in Schleife

0

habe ich gerade entdeckt, eine weitere mögliche Ursache dafür. Wenn die Berechtigungen des Verzeichnisses/Unterverzeichnisses es der ZIP nicht ermöglichen, die Datei zu finden, meldet sie diesen Fehler.Wenn Sie ein chmod -R 444 im Verzeichnis ausführen und dann versuchen, es zu zippen, reproduzieren Sie diesen Fehler und haben auch einen Bericht "0% gespeichert":

zip Warnung: Name nicht matched: borrar/enviar hinzufügen: borrar/(gespeichert 0%)

Versuchen Sie daher, die Berechtigungen der Datei zu ändern. Wenn Sie versuchen, sie per E-Mail zu senden, und diese E-Mail-Filter (wie Google Mail) dumme Filter entwickeln, die keine ausführbaren Dateien senden, vergessen Sie nicht, dass das Erstellen von Berechtigungen bei der Erstellung der Zip-Komprimierung die Ursache für den Fehler sein kann. von "Name nicht gefunden".

1

eebbesen traf den Nagel in seinem Kommentar für meinen Fall (aber ich kann nicht für Kommentar stimmen). Ein weiterer möglicher Grund, der in den anderen Kommentaren übersehen wurde, ist eine Datei, die die Dateigröße überschreitet (4 GB).

1

Eine andere mögliche Ursache, die einen zip warning: name not matched: Fehler erzeugen kann, ist eine der zip Umgebungsvariablen falsch eingestellt.

Aus der Manpage:

ENVIRONMENT 
    The following environment variables are read and used by zip as described. 

ZIPOPT 
    contains default options that will be used when running zip. The contents of this environment variable will get added to the command line just after the zip command. 

ZIP 
    [Not on RISC OS and VMS] see ZIPOPT 

Zip$Options 
    [RISC OS] see ZIPOPT 

Zip$Exts 
    [RISC OS] contains extensions separated by a : that will cause native filenames with one of the specified extensions to be added to the zip file with basename and extension swapped. 

ZIP_OPTS 
    [VMS] see ZIPOPT 

In meinem Fall war ich mit zip in einem Skript und hatte die binäre Lage in einer Umgebungsvariablen ZIP, so dass wir, ohne leicht zu einem anderen zip binär ändern könnten Tonnen von Änderungen im Skript.

Beispiel:

ZIP=/usr/bin/zip 
... 
${ZIP} -r folder.zip folder 

Dies wird dann verarbeitet, wie:

/usr/bin/zip /usr/bin/zip -r folder.zip folder 

und erzeugt den Fehler:

zip warning: name not matched: folder.zip 
zip I/O error: Operation not permitted 
zip error: Could not create output file (/usr/bin/zip.zip) 

Die erste, weil es jetzt versucht folder.zip in das Archiv hinzufügen anstatt es als Archiv zu verwenden. Das zweite und dritte, weil es versucht, die Datei /usr/bin/zip.zip als das Archiv zu verwenden, das (glücklicherweise) von einem normalen Benutzer nicht beschreibbar ist.

Hinweis: Dies ist eine wirklich alte Frage, aber ich habe diese Antwort nirgends gefunden, also posten ich sie, um zukünftigen Suchern zu helfen (mein zukünftiges Selbst eingeschlossen).