Re: 7z command works fine on command line but not in script
Le 19.02.2014 10:53, Scott Ferguson a écrit :
Just read your last post before sending this, so this may no longer
be
relevant... I don't know that you need to quote the variables. I use
coloured bash so it is usually obvious if I need to. P.S. without the
quotes you won't need the escapes - just quote the whole filename
(which
may be what you are lacking).
I use colors too ( and I have no idea about the reason to disable
colors by default in Debian... ) , but I really do not like interpreted
languages. My opinion is that stuff written with them are messy, but at
least, shell is handier than C++ to manage files and shell commands...
so sometimes I try to automate small tasks with it. Maybe someday I will
become efficient with it.
The error was that I had too many quotes, so some of them were included
in the name, but for a reason I can not understand, echo did not
displayed them. I spotted the problem thanks to unzip, which is far
nicer than 7z when it comes to reporting errors to user, because it
shows the exact filename it was trying to process when failed.
I like 7z, it have pretty nice options and can manage almost all format
and compression methods ( I only have found 2 that it can not process,
and one can be if the non-free package is installed, which is better
than any other archiver I know about ) and, which is very important, it
can detect the format alone. Pretty useful for scripts, but when it
fails, it only says it fails, not why it did.
On 19/02/14 20:30, berenger.morel@neutralite.org wrote:
Le 19.02.2014 09:53, Scott Ferguson a écrit :
On 19/02/14 19:47, berenger.morel@neutralite.org wrote:
Hello.
I made a script to extract music from a jamendo archive, but for a
reason I do not know, 7z does not accept the command line. I also
echoed
it, to be able to know what it tries to run, and it works fine
when ran
on command line.
Here is the script:
#!/bin/sh
for i in *.zip;
do
artiste=`echo $i|cut -f1 -d-|sed -e 's/^ *//g' -e 's/ *$//g'`
album=`echo $i|cut -f2 -d-|sed -e 's/^ *//g' -e 's/ *$//g'`
mkdir "$artiste/$album" -p
7z x \"$i\" -o\"$artiste/$album\" || rmdir "$artiste/$album"
-p
echo 7z x \"$i\" -o\"$artiste/$album\"
done
With, for example, this archive:
http://www.jamendo.com/fr/list/a69778/monument, the folders are
correctly created, but it prints:
Error: Incorrect command line
7z x "Shearer - Monument - a69778 --- Jamendo - MP3 VBR 192k.zip"
-o"Shearer/Monument"
Do someone knows what I am doing wrong?
Maybe passing "-" without a recognised qualifier (after the
$artiste/$album\) ??
Kind regards
It does not change anything.
I have some "progress", when I do this:
7z x "\'$i\'" -o"\'$artiste/$album\'"
instead of
7z x \"$i\" -o\"$artiste/$album\"
7z x $i -o $artiste/$album ?
The destination directory needs to be just near the option -o,
otherwise it does not work.
I'm presuming you mean "in the script" (so the variants are
populated).
What happens if you try this from the CLI:-
7z x "Shearer - Monument - a69778 --- Jamendo - MP3 VBR 192k.zip"
It extracts the archive into current directory ( and since jamendo just
archive files without directory, it makes things a lot messy :) )
I'm also presuming you're running the command in the working
directory
(stuff I often overlook).
I did run the script in the directory where the archives I want to
process are, and when I tried the command by hand, I was in the same
place, but it worked.
But the the error become "there is no such archive".
Is it there? i.e.:-
$ ls "Shearer - Monument - a69778 --- Jamendo - MP3 VBR 192k.zip"
It is.
I'd also try renaming it:-
$ cp ""Shearer - Monument - a69778 --- Jamendo - MP3 VBR 192k.zip"
"Shearer-Monument-a69778-Jamendo-MP3 VBR 192k.zip"
and then trying again
I would have done this if I were not able to avoid this manipulation.
I wonder if the
easier would not be to try another unarchiver...
unzip? Though 7z is pretty good.
Kind regards.
Yes, I used unzip to debug the script. This tool actually what it tried
to do if and when it fails, which revealed me that I had too much tries
to escape things. I am really not a script guy btw, and am far more
efficient with strong typed languages, where behaviors are much more
predictable.
Just in case, here is the full working script.
If someone have any comment to make it more secure, reliable, readable
or whatever, I'll be happy to read it. Here, it seems it works like a
charm ( just a little too verbose, but I could easily redirect 7z's
outputs to /dev/null ).
Note that it updates mpd's database and... remove executable flag from
songs, since for a reason I can not see, jamendo set it up! It also
moves the archive out of the way, to allow running the script on next
download without a problem ( downloading a list of archives depending on
album+author or the id number could be an interesting feature, maybe
I'll try to do so later, but it would be smarter to do so in another
script anyway. ).
====================
#!/bin/sh
for i in *.zip;
do
artiste=`echo $i|cut -f1 -d-|sed -e 's/^ *//g' -e 's/ *$//g'`
album=`echo $i|cut -f2 -d-|sed -e 's/^ *//g' -e 's/ *$//g'`
mkdir "$artiste/$album" -p
7z x "$i" -o"$artiste/$album"
mv "$i" ".."
find . -path "./$artiste/$album/*" -exec chmod -x '{}' \;
done
mpc update
====================
Reply to: