Shell/bash

[papibe]

You need to change the coding strategy.

Both your current script, and my debug script look for files only named 'something.rar'.

My guess is that the torrents now come in a different packaging, split, and naming convention. For what you have been saying, that was not the case before. Also, if the script worked before and not now, it also confirms that the naming convention has changed.

A thought:
What happen if you manually unrar, say the 'something.001' file? If it unrars the whole content successfully, then a possible approach would be to find '*.001' files instead of looking for rars.

Let us know what you think, and if you need help with that.
Regards.

[Vaphell]

And as far as your "bet" is concerned... Here's a thumbnail.

that's not a .rar file in a literal sense of having .rar as filename extension.
Globs don't care about what virtual type saved in some pseudo registry the file supposedly belongs to. This is command line we are talking about. CLI tools only care about characters in the filename itself. *.rar will never ever match any .r01 or .001 file, period.


i suggest trying something like find -regextype posix-extended -iregex '.*(rar|r01|001)'

[varunendra]

It's been that way for years. EVERY torrent download I've seen from my friends, and my father included use rar files in that manner - why, I don't know nor do I really care and the point of this thread....

Nope, it never used to be that way, at least not until a couple of years ago when I used to be a hardcore Windows user. And you must care now since the naming convention seems to have changed as papibe pointed out -

My guess is that the torrents now come in a different packaging, split, and naming convention. For what you have been saying, that was not the case before. Also, if the script worked before and not now, it also confirms that the naming convention has changed.

I can confirm that the multi-part rar files used to be ONE .rar file, then .r01, .r02,.... etc. And even windows used (I believe it still does) to only recognize upto the .r05 or probably a few more files (would open them with winrar on double-clicking), not .r06 onwards (won't know what to do with them on double-click). Linux always decides a file-type by looking at its headers, so recognizing them wasn't a problem then nor is now. But that is not the point here.

To extract them, one had to right-click the first file (.rar), which would then extract all the other files automatically. If I remember correctly, one could also open/extract them via those other files (.r01, .r02.... upto .r05 or .r06) that were associated in registry as rar files, thus being recognized as rar archives. But that also is not the point here - the unrar program will probably still do its job as it should. The point is - There USED TO BE a rar file in each set.

You want your script to go in each directory where there are files to extract. To identify and list these directories, you are using 'find' command. Now the find command, in its current form in your script, will -

1) ONLY find and list those directories which have a .rar file in them.
2) If there is no .rar file in a directory, find simply won't list it, period.

If this same script used to work like you want, and if you still have any of those source directories/packages stored anywhere, go look into them - you'll find .rar files in each of them.

If it could help, I could attach multiple screenshots displaying that older naming convention (still can, since I have an XP installation in a VM, and old versions of winrar), but it won't. What can help is understanding the fundamentals of bash or any shell interpreter.

[rhss6-2011]

We're all kinda right - I just found what the real issue is... Interesting enough...

Ok, so after everyone mentioned how the torrents used to be split up and how that changed I took a MUCH closer look at EACH folder and the files within. I came to the conclusion that the one folder where it works properly HAS a .rar file. When I move all 46 r.0* files into a different folder I of course can't extract the contents of the rar. Likewise, when I move the rar file I can't extract it either.
HOWEVER, when I have BOTH the rar AND r.0* files in the folder together it will extract the files.

So, I guess I've been asking the wrong question; the REAL question is, is there a workaround for the torrent downloads that only use the r.0* files? If I randomly click on any of them and extract manually I still get the file. That's what the script is supposed to do...


If I'm not giving a good enough explanation, see the two thumbnails I posted. One shows the files in the folder I need to extract (and the extracted ISO in this case since It's a game of some sort) and the other thumbnail shows my terminal, having gone through all the individual r.0* files to actually extract the iso.


So my script WAS working... just not exactly how I expected it to since this issue never came up in the past.

Any ideas?




EDITED TO ADD THIS:
Is there maybe some way to force my script to recognize the other files as a collective rar like the actual archivemanager program does? In my thumbnail earlier it showed that "filearchiver" or whatever it's called recognizes it for what it is, which enables me to extract the file I want... Any idea on how to implement that into the script, or do I have a few more years to go before I learn enough scripting to figure that one out?

[varunendra]

I came to the conclusion that the one folder where it works properly HAS a .rar file. When I move all 46 r.0* files into a different folder I of course can't extract the contents of the rar. Likewise, when I move the rar file I can't extract it either.
HOWEVER, when I have BOTH the rar AND r.0* files in the folder together it will extract the files.

Exactly what I described already -

..the multi-part rar files used to be ONE .rar file, then .r01, .r02,.... etc....
....
To extract them, one had to right-click the first file (.rar), which would then extract all the other files automatically. If I remember correctly, one could also open/extract them via those other files (.r01, .r02.... upto .r05 or .r06) that were associated in registry as rar files, thus being recognized as rar archives.

Of course all the parts need to be in the same directory. Extraction will be failed/aborted prematurely if even one of those parts (anyone) is missing.

So, I guess I've been asking the wrong question; the REAL question is, is there a workaround for the torrent downloads that only use the r.0* files?

The problem was already understood and possible solutions (easy and simple ones) have already been suggested by our experts -

You need to change the coding strategy.
....
....a possible approach would be to find '*.001' files instead of looking for rars.

i suggest trying something like find -regextype posix-extended -iregex '.*(rar|r01|001)'

Is there maybe some way to force my script to recognize the other files as a collective rar like the actual archivemanager program does?.... Any idea on how to implement that into the script, or do I have a few more years to go before I learn enough scripting to figure that one out?

You don't need to recognize all the files as a collective .rar archive. It only needs to identify only one (any one) of them. It is then the job of the 'unrar' program to automatically detect the other parts (if they are present) and extract them to one complete file (or directory/collection of files).

As such the strategy (suggested by both experts) to look for either .rar, or .r01, or .001 and then execute the unrar command on it should work as good as right-click > extract does.

If you want the script to verify before extracting that the file it found is indeed a rar archive, you can make use of "file" command. For example -

if [ "$(file "$r" | grep "RAR archive")" ]; then
	unrar e -v "$r" $(dirname "$r")
fi

[rhss6-2011]

Alright, well I tried a few different things, and I found the solution (thanks to Vaphell for posting it).

All I had to use was:

  for r in `find -regextype posix-extended -iregex '.*(rar|r01|001|01)'`
    do
      echo "Unpacking in directory: "`dirname $r`
      unrar e -v $r `dirname $r`
    done ;;

and it worked just fine from there...

[papibe]

Hi again.

I believe you are having issues with spaces in both paths and filenames.

In post#3 there's a explanation on how to avoid any problem with spaces, and other special characters. This is important in the long run because you have to consider that some torrents are not originated in English speaking languages, so may even contain non ASCII characters.

The safest approach is to use a while<<find structure like this:

while IFS= read -d $'\0' -r rarfile
do
    echo "Unpacking in directory: "`dirname $rarfile`
    unrar e -v "$rarfile" `dirname "$rarfile"`

done< <(find "$1" -type f -regextype posix-extended -iregex '.*\.(rar|r01|001|01)' -print0)

Although, I recommend taking it a little but further and use:

while IFS= read -d $'\0' -r rarfile
do
    unpack_dir=""${rarfile%/*}""

    echo "Unpacking in directory: $unpack_dir"
    unrar e -v "$rarfile" "$unpack_dir"

done< <(find "$1" -type f -regextype posix-extended -iregex '.*\.(rar|r01|001|01)' -print0)

I hope that helps. Let us know how it goes.
Regards.

P.S.: there could be a minor issue when in a single directory there's a both a 'something.rar' file, and another file called 'something.r01'. The current code would extract the content twice. I don't know how frequent that would be, but let us know if you want to tackle those cases.

[varunendra]

P.S.: there could be a minor issue when in a single directory there's a both a 'something.rar' file, and another file called 'something.r01'. The current code would extract the content twice. I don't know how frequent that would be, but let us know if you want to tackle those cases.

Good point, certainly going to happen with all such archives that have been compressed with older versions of WinRar.

[rhss6-2011]

Hello there,
I haven't been able to implement the tip you gave me for my script to resolve issues with spaces since I'm always... busy... weekends doing whatever with my friends. Anyways, you mentioned how I can run into an issue with "something.rar" and "something.r01"...

Well, I actually noticed that after trying out the updatedT script to find any possible form of "rar" files to extract. Two of my folders had the file.rar within the folder - this meant that the terminal paused and gave me a menu to overwrite, skip, rename, or do something else with the files and wouldn't proceed until I addressed the situation.

Shouldn't I be able to fix that with
"unrar e -v -o+/- $r `dirname $r" - If I use the dash it would tell the terminal NOT to overwrite (but I'm not entirely sure what would happen after that) or if I use the plus sign it'd tell the terminal to just go ahead and overwrite, which I think might not be such a bad idea ultimately...

Any thoughts?

Edited to add this:

Ok, so I tried the code you gave me... and received an error...

     while IFS= read -d $'\0' -r rarfile
	do
    echo "Unpacking in directory: "`dirname $rarfile`
    unrar e -v "$rarfile" `dirname "$rarfile"`
    done <<(find "$1" -type f -regextype posix-extended -iregex '.*\.(rar|r01|001|01)' -print0) ;;

extract.sh: 48: extract.sh: Syntax error: "(" unexpected

What happened? All the brackets are where they belong, and have a closing bracket as well - Not sure how to deal with this one.

[Vaphell]

spaces are important here, it's not

<<(...)

it's

<_<(...)

< (redirection) + <(...) (process substitution)