[patch] Universal unpacking

[birdie]

Currently MC can only compress to different file formats and (un)gzip/(un)bzip.

Oftentimes it's necessary to unpack various file formats without leaving MC. I have added a patch for MC's menu, as well as the unpacker itself (adjust the paths as required).

[gotar]

The code is buggy:

1. I see no reason to use bash,
2. some tests are wrong (numbers should be compared using eq/ne/lt/gt/le/ge operators),
3. what's the point of all that gz magic, wouldn't gzip -d be enough? - I see it's there to keep original gz file, but I'm not sure that all the other decompressors would ask before overwriting files,
4. there are no fallbacks (unrar to rar),
5. how would this work/fail in some VFS?
6. how about uppercase extensions (ZIP)? how about missing ones - detect by magic (file)?
7. why don't you define per-compresor menu entry insted?

IMHO this approach (i.e. creating some tool detached from everything else, not maintained anywhere upstream etc.) is very risky and duplicates current work (VFS). There are file handlers already defined, that is the proper place to make fixes (like aggregating file list to decompress).

[birdie]

Replying to gotar:

The code is buggy:

1. I see no reason to use bash,

bash -> sh will be trivial, besides 99% of PCs which run MC, have BASH installed.

2. some tests are wrong (numbers should be compared using eq/ne/lt/gt/le/ge operators),

You mean the last line? Numbers can be compared using string operations as well.

3. what's the point of all that gz magic, wouldn't gzip -d be enough? - I see it's there to keep original gz file, but I'm not sure that all the other decompressors would ask before overwriting files,

I prefer to leave the original file as is, GZIP cannot do that. All other archivers have -k option which GZIP authors refuse to add.

4. there are no fallbacks (unrar to rar),

If rar is installed, unrar is 100% installed. This fallback is totally unnecessary.

5. how would this work/fail in some VFS?

This won't work on any VFS at all. Currently VFS support in MC is totally broken and unusable - I just don't want to talk about that. That warrants a complete rewrite of MC.

6. how about uppercase extensions (ZIP)? how about missing ones - detect by magic (file)?

I will rework the patch if there's a chance that it'll be merged.

7. why don't you define per-compresor menu entry insted?

IMHO this approach (i.e. creating some tool detached from everything else, not maintained anywhere upstream etc.) is very risky and duplicates current work (VFS). There are file handlers already defined, that is the proper place to make fixes (like aggregating file list to decompress).

OK, let's say we have 20 more archive formats. Do you want MC menu to contain an entry for each and every one of them? The point of this script is to unpack anything you throw at it no questions asked (that's why I run 7z x "$1" as the last measure).

[gotar]

Replying to birdie:

bash -> sh will be trivial, besides 99% of PCs which run MC, have BASH installed.

That's not the point - noone should use non-POSIX shell without some valid reason.

You mean the last line? Numbers can be compared using string operations as well.

If you know the numbers (their notation), sure - but shouldn't.

If rar is installed, unrar is 100% installed. This fallback is totally unnecessary.

That's simply not true. Why should anyone install unrar having full rar?

OK, let's say we have 20 more archive formats. Do you want MC menu to contain an entry for each and every one of them?

AFAIR menu entries are conditional - you can show one only when specific file type is selected.

The point of this script is to unpack anything you throw at it no questions asked.

1. If such tool (in general) is useful, there should exist one already. I've found this: ​http://martin.ankerl.com/files/e

and you might cross-compare features. However it doesn't look to be actively maintained (as there is little or no reason to do so).

2. As much as I don't like the idea, it has already been done for !View/!Open ext actions - see ext.d/archive.sh, this is the script you want to patch with Extract action (and is some-kind of alternate run-mailcap),

3. There is already Extract action mentioned (src/vfs/extfs/helpers/README) and there are some entries in mc.ext, however I can't see them working. It would be best if that worked, as you would have at least common regexp in common place running common script - currently your script should copy e.g. "regex/\.t([gp]?z|ar\.g?[zZ])$|\.ipk$|\.gem$". Moreover, one could use 'type' match. It shouldn't be too hard to mimic ext behaviour inside menu. The problem compared to your approach is that archive.sh actually requires type to be given, and this is parsed by mc core, not some externally accessible script (src/filemanager/ext.c).

[birdie]

Replying to gotar:

Replying to birdie:

bash -> sh will be trivial, besides 99% of PCs which run MC, have BASH installed.

That's not the point - noone should use non-POSIX shell without some valid reason.

The script is already pure SH compatible.

You mean the last line? Numbers can be compared using string operations as well.

If you know the numbers (their notation), sure - but shouldn't.

Fixed already.

If rar is installed, unrar is 100% installed. This fallback is totally unnecessary.

That's simply not true. Why should anyone install unrar having full rar?

That's simply true - when people use a binary rar distribution, then they run Makefile and then they get both installed. If you are willing to accept the patch I will create a workaround for such an incredibly uncommon scenario.

OK, let's say we have 20 more archive formats. Do you want MC menu to contain an entry for each and every one of them?

AFAIR menu entries are conditional - you can show one only when specific file type is selected.

Again the point of this script is to unpack anything you throw at it no questions asked. I don't understand why we're arguing about that. (p)7z understands god knows how many formats (some are not even documented). It can also extract deeply nested archived (i.e. a zip file inside 'exe'). You cannot write an extension handler for that, just cannot. Unix tools, including file won't help either.

The point of this script is to unpack anything you throw at it no questions asked.

1. If such tool (in general) is useful, there should exist one already. I've found this: ​http://martin.ankerl.com/files/e

and you might cross-compare features. However it doesn't look to be actively maintained (as there is little or no reason to do so).

Why use 3d party tools when you have an absolutely easy script to maintain? Seems like you hate my solution so much you'd like to use anything under the Sun (including questionable unmaintainable tools) just to make life difficult. How nice of you.

2. As much as I don't like the idea, it has already been done for !View/!Open ext actions - see ext.d/archive.sh, this is the script you want to patch with Extract action (and is some-kind of alternate run-mailcap),

See above. It's called a universal unpacker for a reason. Again, let's use some arbitrary unix tools just because you don't like my idea. Great!

3. There is already Extract action mentioned (src/vfs/extfs/helpers/README) and there are some entries in mc.ext, however I can't see them working. It would be best if that worked, as you would have at least common regexp in common place running common script - currently your script should copy e.g. "regex/\.t([gp]?z|ar\.g?[zZ])$|\.ipk$|\.gem$". Moreover, one could use 'type' match. It shouldn't be too hard to mimic ext behaviour inside menu. The problem compared to your approach is that archive.sh actually requires type to be given, and this is parsed by mc core, not some externally accessible script (src/filemanager/ext.c).

OK, I get you. You simply don't like it because you don't like it. There are no other sound arguments. I will ask certain distros to include the patch and we're done. Your ego won't be touched. Everyone will be safe.

[gotar]

Replying to birdie:

That's simply true - when people use a binary rar distribution, then they run Makefile and then they get both installed.

$ rpm -ql rar | grep -i unrar | wc -l
0

If you are willing to accept the patch I will create a workaround for such an incredibly uncommon scenario.

I'm not going to accept your patch, only because I'm not mc dev! I'd just like it to be eventually accepted in some decent form, as the idea is obviously good (and I wonder how this happened, that it's not yet implemented).

AFAIR menu entries are conditional - you can show one only when specific file type is selected.

Again the point of this script is to unpack anything you throw at it no questions asked. I don't understand why we're arguing about that.

OK, I don't like the idea of having single script primarily because in some cases it's not possible for a user to adjust it for himself (consider noexec $HOME), while separate menu entries (as well as mc.ext) can be altered one by one. Just take a look at current mc.ext - even with all-in-one archive.sh one can easily remove or change single invocation per-filetype. Having * -> uniunpack one cannot do that, it's all or nothing.
Secondarily, the drop-in supporting solutions are preferred since years (e.g. unpack.d with file handlers). This way user can add rpm or deb extraction easily - which are not supported in your script (only cpio is).

(p)7z understands god knows how many formats (some are not even documented). It can also extract deeply nested archived (i.e. a zip file inside 'exe'). You cannot write an extension handler for that, just cannot. Unix tools, including file won't help either.

OK, so 7z is nice fallback, it extracts ods and rpm files. However if some system lacks this tool, one cannot extract rpm file contents, and your implementation won't allow user to extend it. And if you consider the ones having 7z, there's no point in enumerating other extractors.

1. If such tool (in general) is useful, there should exist one already. I've found this: ​http://martin.ankerl.com/files/e

and you might cross-compare features. However it doesn't look to be actively maintained (as there is little or no reason to do so).

Why use 3d party tools when you have an absolutely easy script to maintain? Seems like you hate my solution so much you'd like to use anything under the Sun (including questionable unmaintainable tools) just to make life difficult. How nice of you.

It's not like that, maybe I wasn't clear enough. If there were some actively maintained upstream solution for general purpose, I would be hardly against creating something new. As there is no such tool, I've gave you the one I've found the most complete for you to check filetypes, handling etc.

2. As much as I don't like the idea, it has already been done for !View/!Open ext actions - see ext.d/archive.sh, this is the script you want to patch with Extract action (and is some-kind of alternate run-mailcap),

See above. It's called a universal unpacker for a reason. Again, let's use some arbitrary unix tools just because you don't like my idea. Great!

This arbitrary unix tool is part of mc... This time I don't get you, please read again my last two points.