Ticket #2118 (closed enhancement: fixed)

Opened 7 years ago

Last modified 4 years ago

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

Reported by: zaytsev Owned by: slavazanko
Priority: major Milestone: 4.8.4
Component: mc-core Version: master
Keywords: Cc: gotar@…, ip1024@…
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description (last modified by zaytsev) (diff)

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.

Change History

comment:1 Changed 7 years ago by 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.

comment:2 follow-up: ↓ 7 Changed 7 years ago by 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.

comment:3 follow-up: ↓ 9 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by slavazanko

and this enhancement shall be stay old behaviour untouched.

In additional: untouched as possible... ;)

comment:6 Changed 7 years ago by 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.

comment:7 in reply to: ↑ 2 ; follow-up: ↓ 10 Changed 7 years ago by 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

comment:8 Changed 7 years ago by gotar

  • Cc gotar@… added

Replying to zaytsev:
@zaytsev:

comment:9 in reply to: ↑ 3 Changed 7 years ago by 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.

comment:10 in reply to: ↑ 7 ; follow-up: ↓ 12 Changed 7 years ago by 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.

comment:11 Changed 7 years ago by zaytsev

  • Description modified (diff)

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?

comment:12 in reply to: ↑ 10 Changed 7 years ago by 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.

comment:13 Changed 7 years ago by zaytsev

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

comment:14 Changed 7 years ago by 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.

comment:15 Changed 6 years ago by igorp1024

  • Cc ip1024@… added

comment:16 Changed 5 years ago by andrew_b

  • Blocking 1721 added

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

comment:17 Changed 5 years ago by andrew_b

  • Branch state set to no branch
  • Milestone changed from 4.7 to Future Releases

comment:18 Changed 5 years ago by slavazanko

  • Owner set to slavazanko
  • Status changed from new to accepted
  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8

Created branch 2118_mcext_enhancement
Initial changeset:08a23e700f66e744d8d3b5d5a65aed6fdeeb96d4

Review, please.

Version 0, edited 5 years ago by slavazanko (next)

comment:19 Changed 5 years ago by slavazanko

  • Blocking 2739 added

comment:20 Changed 5 years ago by slavazanko

  • Blocking 2103 added

comment:21 Changed 5 years ago by slavazanko

  • Blocking 2117 added

comment:22 Changed 5 years ago by slavazanko

  • Blocking 1686 added

comment:23 Changed 5 years ago by slavazanko

  • Blocking 2664, 2747 added

comment:24 Changed 5 years ago by slavazanko

  • Blocking 2747 removed

(In #2747) Ops, sorry, errorneus blockedBy

comment:25 Changed 5 years ago by slavazanko

  • Blocking 2746 added

comment:26 Changed 5 years ago by slavazanko

  • Blocking 2751 added

comment:27 Changed 5 years ago by andrew_b

  • Blocking 2767 added

comment:28 Changed 5 years ago by andrew_b

  • Blocking 1721 removed

(In #1721) See #2767.

comment:29 Changed 5 years ago by slavazanko

  • Branch state changed from on review to on rework

comment:30 Changed 5 years ago by slavazanko

  • Branch state changed from on rework to on review

Branch rebased to current master. Review, please

comment:31 Changed 5 years ago by slavazanko

  • Milestone changed from 4.8 to 4.8.4

comment:32 Changed 5 years ago by slavazanko

  • Blocking 2673 added

comment:33 Changed 5 years ago by slavazanko

  • Blocking 2723 added

comment:34 Changed 5 years ago by andrew_b

  • Votes for changeset set to andrew_b

comment:35 Changed 5 years ago by angel_il

  • Votes for changeset changed from andrew_b to andrew_b angel_il
  • Branch state changed from on review to approved

comment:36 Changed 5 years ago by slavazanko

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b angel_il to committed-master
  • Resolution set to fixed
  • Blocking 1686, 2103, 2117, 2664, 2673, 2723, 2739, 2746, 2751, 2767 removed

merged to master:

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

comment:37 Changed 5 years ago by slavazanko

  • Status changed from testing to closed

comment:38 Changed 4 years ago by andrew_b

#2858 fixes segfault after this issue.

comment:39 Changed 4 years ago by andrew_b

  • Branch state changed from approved to merged
Note: See TracTickets for help on using tickets.