The ext.d/*sh construction to open a file from MC is overcomplicated

[covex]

I am somehow missing the reasoning for the existing way of opening files from mc.

Now we do not have only mc.ext with the definitions of actions, which is system wide configurable in /etc/mc/mc.ext, but we also have a shell constructions in /usr/libexec/mc/ext.d, which is not configurable anymore. The purpose is probably only to select either some app or xdg-open for an open action.

Setting the MC_XDG_OPEN=false makes no sense as the app to open the file is only present in ext.d/*.sh file, which you should not change, so you have to change the mc.ext anyway.

This makes the process of file opening slow as many shell script code needs to be interpreted to get as simple thing as file open in desired app and pain to understand what is going on as the xdg-open itself is quite complicated - it uses either /usr/share/application/default.list or ~/.local/share/applications/mimeapps.list

Let's see the mc.ext e.g. for images:

type/^PBM
        Include=image
        
type/^PGM
        Include=image
        
type/^PPM
        Include=image
        
type/^Netpbm
        Include=image
        
shell/.xcf
        Open=/usr/libexec/mc/ext.d/image.sh open xcf
        
shell/.xbm
        Open=/usr/libexec/mc/ext.d/image.sh open xbm
        
shell/i/.svg
        View=%view{ascii} /usr/libexec/mc/ext.d/image.sh view svg
        Open=/usr/libexec/mc/ext.d/image.sh open svg

include/image
        Open=/usr/libexec/mc/ext.d/image.sh open ALL_FORMATS
        View=%view{ascii} /usr/libexec/mc/ext.d/image.sh view ALL_FORMATS

here we see we can simply share the common app thru include, no need for another image.sh.

Now what is in image.sh?

do_open_action() {
    filetype=$1

    case "${filetype}" in
    xbm)
        bitmap "${MC_EXT_FILENAME}"
        ;;
    xcf)
        (gimp "${MC_EXT_FILENAME}" &)
        ;;
    svg)
        (inkscape "${MC_EXT_FILENAME}" &)
        ;;
    *)
        if [ -n "$DISPLAY" ]; then
            (gqview "${MC_EXT_FILENAME}" &)
        elif see >/dev/null 2>&1; then
            (see "${MC_EXT_FILENAME}" &)
        else
            zgv "${MC_EXT_FILENAME}"
        fi
        ;;
    esac
}

It just acts on the same kind of file type but thru a shell case construction and hardcodes the apps that should be used. If xdg-open is used, then it starts another shell script, that based on the file type (again) uses the default app from either system wide unconfigurable setting or local user definition.

Overall this all is a mess. Please keep this as simple as possible. If you want to relay on xdg-open, just use xdg-open in the mc.ext and let user simply reconfigure it instead of digging around another shell scripts.

[andrew_b]

Replying to covex:

Now we do not have only mc.ext with the definitions of actions, which is system wide configurable in /etc/mc/mc.ext, but we also have a shell constructions in /usr/libexec/mc/ext.d, which is not configurable anymore.

Also you have ~/.config/mc/mc.ext where you can redefine any action as you wish. If ~/.config/mc/mc.ext is used, /etc/mc/mc.ext is not used at all.

This makes the process of file opening slow

How slower? 2, 5 or 10 times?

Overall this all is a mess. Please keep this as simple as possible. If you want to relay on xdg-open, just use xdg-open in the mc.ext and let user simply reconfigure it instead of digging around another shell scripts.

I would close this ticket as WONTFIX because of user's complete freedom in his ~/.config/mc/mc.ext.

[covex]

I am not interested in per user definition, but a system wide. You of course have a full freedom to completely rewrite the /etc/mc/mc.ext and remove all the references to images.sh, video.sh or whatever. I am arguing for removing this complecated way for app starting.

First of all I do not see a reason for existance of MC_XDG_OPEN, because setting it off puts you in the situation, that you still have to remove the references to ext.d from mc.ext as the apps are hard coded into those shell scripts.

Then I am arguing against existance of ext.d scripts as the same thing then can be achieved in the global mc.ext and all this is noticably faster.

I do not know how to measure precisely the delay between pressing Enter on a file and app start, but at the moment, and on my hardware (where I do have SSD) I see delay, making me unsure if the app is launched or is just missing, which was not the case for all the years I use MC.

To sum up the chain implemented now in MC:

Clicking on .png -> type/PNG Include=image -> include/image Open=/usr/libexec/mc/ext.d/image.sh open ALL_FORMATS -> xdg-open .png (now xdg determines mimetype .png, finds the app and stars the .desktop file)

While we could do the xdg-open in the include/image directly or we do not need to determine file type at all because this is what xdg-open does - if we want xdg to be a default tool to open apps.

Or

Clicking on .png with MC_XDG_OPEN=false > type/PNG Include=image -> include/image Open=/usr/libexec/mc/ext.d/image.sh open ALL_FORMATS -> case "${filetype}" in *) gqview "${MC_EXT_FILENAME}" &

hardcodes the app that is normaly configurable in include/image.

I see no reason for ext.d to exist.

[andrew_b]

Replying to covex:

I see no reason for ext.d to exist.

Just compare:

was (before #2118):

# html
regex/\.([hH][tT][mM][lL]?)$
        Open=(if test -n "@X11_WWW@" && test -n "$DISPLAY"; then (@X11_WWW@ file://%d/%p &) 1>&2; else links %f || lynx -force_htm %f || ${PAGER:-more} %f; fi) 2>/dev/null
        View=%view{ascii} links -dump %f 2>/dev/null || w3m -dump %f 2>/dev/null || lynx -dump -force_html %f

now:

# html
regex/i/\.html?$
        Open=@EXTHELPERSDIR@/web.sh open html
        View=%view{ascii} @EXTHELPERSDIR@/web.sh view html

Do you really like complicated unreadable shell scripts within mc.ext? If you add xdg-open support there, you get the real nightmare.

[covex]

The new scheme does not allow me to use e.g. elinks instead of links as the construction is in script I should not modify. It is much more clear to me, what is happening on file open when the app is present in mc.ext, than the construction with the external script (and it is faster too).

If xdg-open is used, then you do not need to do any file extension handling, as xdg-open does it based on file mime type database.

I understand now at least that this was made based on #2118 to incorporate the xdg-open. I am not alone to complain that xdg-open is using as a fallback to open any file a web browser - with this scheme now everything for me opens in a web browser, usually with "save as" dialog. However if this works OK for majority of users, then I am fine with that - I'll rewrite the mc.ext to suite my needs (i.e. revert it back to previous version).

Thanks for attention.

[andrew_b]

Replying to covex:

The new scheme does not allow me to use e.g. elinks instead of links

That's wrong. You can do that in your ~/.config/mc/mc.ext. Why do you want modify system config instead of user one?

[covex]

Because there are more users on the system, and this makes troubles to all of them.

[slavazanko]

The new scheme does not allow me to use e.g. elinks instead of links as the construction is in script I should not modify. It is much more clear to me, what is happening on file open when the app is present in mc.ext, than the construction with the external script (and it is faster too).

Why do you want modify system config instead of user one?

Because there are more users on the system, and this makes troubles to all of them.

Please, feel free to change your @EXTHELPERSDIR@/web.sh for replacing 'links' by 'elinks'. Remove the call to xdg-open from web.sh if you want.

[covex]

Gentlemen, thanks for the help, even thou I was not asking for help, but was trying to say, the existing procedure for app opening in MC is way too complicated, hard to change and slow.

If you consider this fine for most users, we are done here, feel free to close this. I just hope this will help others looking for a reason MC is now opening everything in the web browser.

[ossi]

i agree that the additional indirection of the new mechanism is, errm, "suboptimal". i've argued for a different approach already in #2118.