Ticket #4861: add extension-based fallbacks for handling JAR and WAR files to mc.ext

[gerardbosch]

Proposed changes

Fix/add support for JAR/WAR files with shell associations.

The file command apparently behaves inconsistently between Linux distributions—that prevents opening JAR files (which are just ZIP files with metadata) in Manjaro/Arch Linux within Midnight Commander; and inspecting/editing source code within those compressed files.

WAR files were missing (that was reported here): https://bugs.launchpad.net/mc/+bug/2062968/comments/16 - this PR adds support for them via extension match.

• Resolves: Cannot open .jar files: file output doesn't match & missing [jar-by-shell] #4861

Checklist

👉 Our coding style can be found here: https://midnight-commander.org/coding-style/ 👈

• I have referenced the issue(s) resolved by this PR (if any)
• I have signed-off my contribution with git commit --amend -s
• Lint and unit tests pass locally with my changes (make indent && make check)
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)

[ossilator]

i find the whole approach mildly fishy; see the inline comment.

---

the lines in the commit message are a bit long.

[ossilator]

that's the wrong keyword here.

[zyv]

Yep 👍

[ossilator]

rather than duplicating the whole thing, a regex match would be preferred.

[zyv]

As the submitter predictably disappeared, as it usually turns out to be the case, I have updated the code myself.

[ossilator]

based on the addition of .war handling below, it would seem logical to add it here as well, or does no file variant recognize these as anything other than a regular zip archive?

actually, what are the files recognized as? you're not saying in the commit message.

the idea behind using content based detection is to catch files with non-standard extensions (for .jars, that may be modules in some applications). falling back to extension based detection is basically admitting defeat ...

[zyv]

As far as I understand, wars are nothing other than jars, only meant to be uploaded to the application servers, so file output would be the same for both. In this sense, they have always been implicitly supported, or at least they should have been.

Given a number of recent posts to #4862 tickets, however, I think indeed it's time to admit defeat and add extension-based fallbacks. It seems that the problem is that even though we are now correctly matching on the file output, the utility itself is unreliable and often enough doesn't detect the correct type.

[ossilator]

.wars contain additional metadata, so they could be detected separately.

i'd really like to see the exact status quo documented (in the commit message), so it's obvious what is being worked around and that this is the only reasonable way to do it.

[azazar]

Why not identify files by content when extension associations search fails? Like Far Manager does.

[zyv]

Why not identify files by content when extension associations search fails? Like Far Manager does.

This PR does exactly the opposite: identify by extension if content search fails (which apparently happens for a surprisingly high number of users even after all the fixes that we've made to it).

[ossilator]

you could use [jw] instead of (j|w). i have no preference.

[ossilator]

.wars contain additional metadata, so they could be detected separately.

i'd really like to see the exact status quo documented (in the commit message), so it's obvious what is being worked around and that this is the only reasonable way to do it.