ubuntuusers.de

Hallo,

ich habe folgende Frage. Ich will mir ein Script schreiben welches mir ein *.zip Archiv in einen Ordner entpackt, der den selben Namen trägt wie das Archiv. Allerdings fehlt mir noch der Ansatz für das Script. Gedacht hatte ich etwa an folgendes:

#! /bin/bash

mkdir NAME_DES_ARCHIVES
cp ARCHIV_IN_EBEN_ERSTELLTEN_ORDNER
unzip NAME.zip

zum entpacken wuerder ich dann jedesmal das Skript aufrufen. Allerdings habe ich jetzt das Problem, dass ich ja den Archivnamen nicht pauschal kenne. Gibt es einen befehl mit dem ich den Namen auslesen und so das vezeichnis erstellen kann?

MfG

Der erste Parameter ist in der Variable $1, der 2. in $2 usw und alles zusammen ist in $* zu finden.

Um das ".zip" für den Dateinamen abzuschneiden könnte man z.B.

echo "$1"|sed -e 's/.zip//'

benutzen.

Eigentlich ist es usus, nicht nur den Inhalt eines Ordners, sondern den ganzen Ordner zu packen, wenn der ganze Ordner benötitgt wird.
Solltest Du also die Archive selbst gepackt haben, dann solltest Du die Packstrategie ändern.
Packt sie jmd. anderes, dann sollte der seine Packweise überdenken.

Es sind natürlich Ausnahmefälle denkbar, in denen das nicht geht.
Was auch nicht geht ist Dein Script.
Wieso kommen da eigentlich 3 unterschiedliche Namen vor?
Angenommen das Archiv heißt abc.zip:

#! /bin/bash
NAME=$(basename $1 .zip)
mkdir $NAME
mv $1 $NAME
cd $NAME
unzip $1

sed ist zwar auch ein schönes Programm, aber basename scheint mir in dem Falle einleuchtender.

@ userunknown: VIELEN DANK!! Genau das ist es was ich auch machen wollte, aber da reicht meine (Un-)Fähigkeit halt noch nicht zu.
Das mit der Packstrategie ist so eine Sache. Unser Prof hat die Angewohnheit imemr nur einzelne Dateien zu packen, und nicht einen Ordner, und es nervt auf Dauer ein wenig, wenn man in einem Ordner dann 30 ungeordnete Dateien rumfliegen hat.

Also nochmal danke an alle!

MfG

Der normale Gnomeentpacker sollte eigentlich erkennen, ob es einen übergeordneten Ordner mit dem Namen des Archivs gibt und wenn nicht den Ordner Archivname_FILES erzeugen.

@uu Hast natürlich recht.

Ich würde noch empfehlen grundsätzlich beim Zugriff auf Variablen doppelte Anführungszeichen zu benutzen. Irgendwie sehe ich das sehr selten hier, bin wohl der einzige, der damit rechnet auch mal Leerzeichen in Pfaden/Dateinamen zu haben.

marc@s8n:~$ TEST='foo/bar baz.zip'
marc@s8n:~$ basename $TEST .zip
basename: extra operand `.zip'
Try `basename --help' for more information.
marc@s8n:~$ basename "$TEST" .zip
bar baz

In der Welt von user unknown gibt es keine Leer- oder Sonderzeichen in Dateinamen 🤣

adun hat geschrieben:

In der Welt von user unknown gibt es keine Leer- oder Sonderzeichen in Dateinamen 🤣

☺ Richtig!
Leerzeichen in Dateinamen sind evil, weil man da immer extra Tipparbeit bekommt.
Also habe ich überlegt, ob es besser ist, Dateinamen grundsätzlich mit Anführungsstrichen zu klammern, oder der ganzen Welt mein Dogma vom verbotenen Leerzeichen aufzudrängen, und kam zu dem Schluß, daß mir letzteres lieber ist, auch wenn es nicht unbedingt leichter ist.

adun hat geschrieben:

Um das ".zip" für den Dateinamen abzuschneiden könnte man z.B.

echo "$1"|sed -e 's/.zip//'

benutzen.

Das ist wohl eher "useless use of sed" 😉
Das Entfernen eines Suffix erledigt man besser so:

[lunar@nargond]-[19:25:26] >> ~
--> FILENAME="test.zip"

[lunar@nargond]-[19:25:37] >> ~
--> echo ${FILENAME%%.*}
test

user unknown hat geschrieben:

Leerzeichen in Dateinamen sind evil, weil man da immer extra Tipparbeit bekommt.
Also habe ich überlegt, ob es besser ist, Dateinamen grundsätzlich mit Anführungsstrichen zu klammern, oder der ganzen Welt mein Dogma vom verbotenen Leerzeichen aufzudrängen, und kam zu dem Schluß, daß mir letzteres lieber ist, auch wenn es nicht unbedingt leichter ist.

Ahh, jetzt weiß also, wo diese ganze kaputten Anti-Leerzeichen-Skripte ihren Ursprung haben... 😉
Mögest du in der Hölle vor hunderten, nein besser tausenden Leerzeichen-verseuchten Dateisystemen schmoren :twisted:

Lunar hat geschrieben:

Das Entfernen eines Suffix erledigt man besser so:

[lunar@nargond]-[19:25:26] >> ~
--> FILENAME="test.zip"

[lunar@nargond]-[19:25:37] >> ~
--> echo ${FILENAME%%.*}
test

Probier das mal mit der Datei foo.bar.zip, oder noch besser: .xsession-errors.sik

Lunar hat geschrieben:

user unknown hat geschrieben:

Leerzeichen in Dateinamen sind evil, weil man da immer extra Tipparbeit bekommt.
Also habe ich überlegt, ob es besser ist, Dateinamen grundsätzlich mit Anführungsstrichen zu klammern, oder der ganzen Welt mein Dogma vom verbotenen Leerzeichen aufzudrängen, und kam zu dem Schluß, daß mir letzteres lieber ist, auch wenn es nicht unbedingt leichter ist.

Ahh, jetzt weiß also, wo diese ganze kaputten Anti-Leerzeichen-Skripte ihren Ursprung haben... 😉
Mögest du in der Hölle vor hunderten, nein besser tausenden Leerzeichen-verseuchten Dateisystemen schmoren :twisted:

Diese Hölle ist in wenigen Minuten wieder bewohnbar, dank:

find / -name "* *" -exec rm {} \;

user unknown hat geschrieben:

Probier das mal mit der Datei foo.bar.zip, oder noch besser: .xsession-errors.sik

Danke für den Hinweis. Natürlich funktioniert das Ganze nur mit einem Prozentzeichen:

[lunar@nargond]-[20:26:08] >> ~/.mozilla/firefox
--> TEST="foo.bar.zip"

[lunar@nargond]-[20:27:13] >> ~/.mozilla/firefox
--> echo ${TEST%.*}
foo.bar

[lunar@nargond]-[20:27:23] >> ~/.mozilla/firefox
--> TEST=".xsession-errors.sik"

[lunar@nargond]-[20:27:41] >> ~/.mozilla/firefox
--> echo ${TEST%.*}
.xsession-errors

user unknown hat geschrieben:

Diese Hölle ist in wenigen Minuten wieder bewohnbar, dank:

find / -name "* *" -exec rm {} \;

Natürlich geht das nicht: Der Teufel hat extra für dich alle möglichen Progamme (selbst den Kernel) gepatcht. Selbst /proc und /sys sind jetzt gerammelt voll mit lauter bösen, gemeinen, hinterhältigen Leerzeichen :twisted:

Lunar hat geschrieben:

Selbst /proc und /sys sind jetzt gerammelt voll mit lauter bösen, gemeinen, hinterhältigen Leerzeichen :twisted:

Oh! Diese Verbrecher!

Ich habe kein Mitleid... :twisted: