Use xdg-open by default in mc.ext.in if present to open files, fallback on current scheme otherwise

[zaytsev]

There've been a huge number of tickets requesting mc.ext.in modifications, some of which are not fixed yet:

#1452
#1686
#1721
#1800
#2103
#2117

Some of these changes are conflicting and different users prefer different associations, so controversy is inevitable.

I suggest to change the current logic to a more versatile: if xdg-utils are present on the system ( ​http://portland.freedesktop.org/wiki/ , all modern Linux distributions, such as Ubuntu / Debian, Fedora, RHEL etc.) try to use xdg-open to open the file. Otherwise fallback on the traditional associations scheme.

xdg-open uses mime-type associations set by the user to start the appropriate application, therefore, one might use his desktop controls to centrally manage file associations at will.

[ossi]

note however that most/all viewers & editors registered in xdg-open rely on $DISPLAY being set.

a approach which is geared for greater console-compatibility is debian's run-mailcap tool. the underlying system is the /etc/mailcap file (which is a very old standard).

using "file -i" (or "file --mime-type") to use more standardized type patterns should also be considered.

[zaytsev]

What's wrong with relying upon $DISPLAY being set correctly?

I know about mailcap and actually we've now came up with a Debian specific patch to re-route all the calls through run-mailcap. However, the problem is that run-mailcap is mostly not available other than on Ubuntu / Debian. There are no Fedora / RHEL packages in the wild and I didn't see anything for Suse either. Bundling run-mailcap with mc does not sound like a terribly good idea, reinventing it is not compelling either.

xdg-utils should be available everywhere and it looks like a reasonable compromise to me.

[slavazanko]

Hm... in summary we will have different 'file-opener' systems:

• 'xdg-open' (if present on FS)
• 'run-mailcap' from debian (if present on FS)
• '/etc/mailcap' (with own parser of mailcap?). Is we need for this?
• ${sysconfdir}/mc/mc.ext (or ~/bindings) with own parser of mc.ext ('file' now used at this point).

Work will continue with first found file-opener from list, but need to respect mc.ext in proir of any others file-openers (for redeclare default reaction)... Hm... As relult, we need for next config-files:

${sharedata_dir}/mc/mc.ext::
this file described reaction for all known files (as mc do it now)

${sysconf_dir}/mc/mc.ext::
this file will redefine reactions for previously founded file-opener)

~/.mc/bindings

User redifinitions.

Is this make sense? Or we need just for xdg-open? Or need to recognize availbe utils at './configure' stage?

P.S. This is just thinks for making 'mental picture' of own 'meta file opener' subsystem :)

P.P.S. Discuss are welcome here.

[slavazanko]

xdg-utils should be available everywhere and it looks like a reasonable compromise to me.

Hey, personally I don't know is these utils is availbe on AIX, HP/UX, Solaris and much other exotic(as for me) OS'es. IMHO, we need to respect all people, who want to use mc... and this enhancement shall be stay old behaviour untouched.

[slavazanko]

and this enhancement shall be stay old behaviour untouched.

In additional: untouched as possible... ;)

[zaytsev]

Slava: xdg-utils are available on Solaris (at least on OpenSolaris?).

In what concerns the last remark, I do not understand how using xdg-utils if available and mc.ext.in settings otherwise will break anything for AIX users.

[ossi]

Replying to zaytsev:

What's wrong with relying upon $DISPLAY being set correctly?

no $DISPLAY on a linux console is correct, still xdg-open won't work. it's for desktop environments, you know. ;-)
given that mc is a common admin tool on headless systems, any hard requirement of x11 tools is completely out of question. it doesn't matter to how many systems these tools were ported.

run-mailcap (or anything mailcap-based) can be only a fallback anyway:

• it makes no distinction between opening, viewing and editing. the mailcap man page says it is only for viewing, so editors are only used if no pure viewer is available.
• for some file types (say .so files) there is typically no mailcap entry. but we want some useful output for them.

preliminary conclusions:

• unify the file type system. base everything on mime types (with an additional compression flag on top). basically, file -z -i. possibly use libmagic directly.
• first query mc.ext for everything
• open: if there is no override and $DISPLAY is set, try xdg-open, otherwise do nothing
• view: if there is no override, try mailcap entry (run-mailcap is rather simple, so just re-implement it internally), otherwise use configured viewer
• edit: if there is no override, use configured editor

[gotar]

Replying to zaytsev:
@zaytsev:

• xdg-utils is X Window System-oriented, so it could be only some preliminary or fallback solution (it's defined as X11_WWW in PLD Linux package),
• xdg-open doesn't distinguish view/open/edit actions,
• you can take run-mailcap from ​http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/mailcap/run-mailcap

[gotar]

Replying to slavazanko:

• 'run-mailcap' from debian (if present on FS)
• '/etc/mailcap' (with own parser of mailcap?). Is we need for this?

This code could be easily bundled (see my previous comment).

Or we need just for xdg-open? Or need to recognize availbe utils at './configure' stage?

These would be definitely bad ideas. The first one makes in unusable on non-X shells (consider remote terminals!), the second one causes the decision to be made on distro level (i.e. users are forced to someone's else choice).

P.S. This is just thinks for making 'mental picture' of own 'meta file opener' subsystem :)

There is already a standard EXACTLY for this job: /etc/mailcap - please just consider this fact and answer is simple, that it is the way to go. The question remains, how to use it: someone already did run-mailcap, so I don't even see a place for discussion.

And BTW add #2103 to the listed tickets.

[gotar]

Replying to ossi:

run-mailcap (or anything mailcap-based) can be only a fallback anyway:

That's right.

• it makes no distinction between opening, viewing and editing. the mailcap man page says it is only for viewing, so editors are only used if no pure viewer is available.

Not true:

Use: /usr/bin/run-mailcap <--action=VAL> [--debug] [MIME-TYPE:[ENCODING:]]FILE [...]

action specify what action to do on these files (default=view)

actions include: view, edit, compose and print.

Please take a look how it can be used at:
​http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/mailcap/mailcap
​http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/lesspipe/lesspipe.sh

preliminary conclusions:

• unify the file type system. base everything on mime types (with an additional compression flag on top). basically, file -z -i. possibly use libmagic directly.

regexp matches must stay (and there's a need for case-insensitive flag).

• first query mc.ext for everything
• open: if there is no override and $DISPLAY is set, try xdg-open, otherwise do nothing

If no mc.ext entry exists and $DISPLAY is not set one can assume, that open=view+pager. See 9. and 10. in #2103.

• view: if there is no override, try mailcap entry (run-mailcap is rather simple, so just re-implement it internally), otherwise use configured viewer

Believe me, it's not so simple;) And it would be stupid to reinvent somenthing that already exists.

[zaytsev]

The only thing that bothers me about mailcap is that it should be then bundled internally with mc. gotar, to make the long story short, what changes do you suggest after bundling mailcap?

[ossi]

Replying to gotar:

Replying to ossi:

• it makes no distinction between opening, viewing and editing. the mailcap man page says it is only for viewing, so editors are only used if no pure viewer is available.

Not true:

actions include: view, edit, compose and print.

right, i read only the first line of the man page. anyway ...
"edit" seems to be a non-standard extension. at least the mailcap man page does not say that it exists. which doesn't mean that we can't use it, only that we have another argument why we can't rely solely on mailcap.
and then there is still the "view" vs. "open" thing. i think it can be mostly interpreted to mean that copiousoutput is "view", while "the other one" is "open".

preliminary conclusions:

• unify the file type system. base everything on mime types (with an additional compression flag on top). basically, file -z -i. possibly use libmagic directly.

regexp matches must stay (and there's a need for case-insensitive flag).

i assume you mean extension matches.
they should stay for performance, if nothing else. but they should be still transformed into mime types, so one doesn't have to mix different types of rules.
the freedesktop mime spec has provisions for both extension matching and magic detection, with reliability information and priorities.

• first query mc.ext for everything
• open: if there is no override and $DISPLAY is set, try xdg-open, otherwise do nothing

If no mc.ext entry exists and $DISPLAY is not set one can assume, that open=view+pager. See 9. and 10. in #2103.

it could mean "edit" just as well ... it does for (some?) source files. not that i like that, actually ...

• view: if there is no override, try mailcap entry (run-mailcap is rather simple, so just re-implement it internally), otherwise use configured viewer

Believe me, it's not so simple;)

it actually is. i read the whole run-mimetype script and found nothing which would have surprised me. except that with glib functions it can be written somewhat more nicely in some places (the shell quoting in particular).

And it would be stupid to reinvent somenthing that already exists.

i don't think mc should incorporate a perl script, and just using it via a hard(?) dependency is no option as well, as one wants to use the internal viewer as the pager for the copiousoutput case.

[zaytsev]

So your suggestion would be basically to re-implement our own mailcap parser taking into account all of the above?

[ossi]

i think so ...
and if things go well, mc.ext could be replaced by just another mailcap file which would take priority over the others from the system.

a second system to map extensions to mime types is still needed, though. i think the freedesktop spec with a fallback on mime.types would do. or just leave out the freedesktop part, but that's probably unwise.

[andrew_b]

(In #1721) The unconditional usage of xdg_open is not well way.

[slavazanko]

Created branch 2118_mcext_enhancement

Review, please.

[slavazanko]

(In #2747) Ops, sorry, errorneus blockedBy

[andrew_b]

(In #1721) See #2767.

[slavazanko]

Branch rebased to current master. Review, please

[slavazanko]

merged to master: [ff6d7b2b084c2097408e0525b83e0bfe0110543e]

git log --pretty=oneline e944301..5c6ae10

[andrew_b]

#2858 fixes segfault after this issue.