How to change default shell used to run user menu scripts

[marcelpaulo]

I have looked everywhere and cannot find where and how to tell mc to use bash to run user menu scripts. I can see it uses sh by default, but I'd imagine and expect that this can configured, so that other shell is used instead.

Output from mc -V:

GNU Midnight Commander 4.8.14
Built with GLib 2.42.0
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

I'm running Xubuntu 14.10

[andrew_b]

Replying to marcelpaulo:

I have looked everywhere and cannot find where and how to tell mc to use bash to run user menu scripts. I can see it uses sh by default,

Yes, /bin/sh is hardcoded (src/filemanager/usermenu.c:455).

but I'd imagine and expect that this can configured, so that other shell is used instead.

The possible solution is environment variable, say, MC_USERMENU_SHELL.

[marcelpaulo]

@andrew_b, environment variable MC_USERMENU_SHELL would be perfect !

[ossi]

i don't think it's a particularly good idea to make the shell configurable - next thing you know is someone trying to use csh and complaining that it doesn't work.

instead, i'd say that if your user menu scripts are complex enough to justify usage of bash extensions, you probably should externalize them to proper scripts and call them from the menu.

[marcelpaulo]

next thing you know is someone trying to use csh and complaining that it doesn't work.

No matter which shell is used, someone might always complain that his/her script is not working — it might happen also with sh ... Whatever shell is used, it's not mc's problem if the script doesn't work.

instead, i'd say that if your user menu scripts are complex enough to justify usage of bash extensions, you probably should externalize them to proper scripts and call them from the menu.

The issue here is not script complexity (it's not the case of arguing which shell is more appropriate) but freedom to use whatever shell one feels more comfortable with.

[ossi]

the point is that if somebody sets csh, (some of) the predefined entries will stop working. additionally, the filename quoting rules will be wrong.

as bash is an almost perfect superset of sh, the only freedom it adds is to use its extensions, which isn't justified unless it significantly reduces the complexity. given the downsides (complexity in mc, hard to discover (which means you'd be pretty much the only user of it ever), potential for incorrect use and thus hard to identify bugs), i'm not a big fan of adding this "freedom".

[marcelpaulo]

the point is that if somebody sets csh, (some of) the predefined entries will stop working. additionally, the filename quoting rules will be wrong.

Point taken, can't argue against it.

as bash is an almost perfect superset of sh, the only freedom it adds is to use its extensions, which isn't justified unless it significantly reduces the complexity. given the downsides (complexity in mc, hard to discover (which means you'd be pretty much the only user of it ever), potential for incorrect use and thus hard to identify bugs), i'm not a big fan of adding this "freedom".

If the environment variable wasn't set, it makes sense to me that sh should still be the default, so it wouldn't affect anybody that didn't explicitly set it. I'm not arguing to set bash as the default, but have a mechanism in place to configure the default.

Neither you, @ossi, nor myself can tell for sure how many people would welcome and use a configurable shell for user menus. And one can use incorrectly any shell ... ( one might argue: sh makes quoting more error-prone than bash). But what's being discussed here is not the relative benefits of any shell, but the freedom to choose.

The fact is, strictly from a user's perspective: the user menus is a fabulous feature, at least for myself it beats any other file manager out there (mc is the only file manager I have used ever since I started using Linux on my laptop), and being able to code the scriptlets in bash would make certain constructs simpler.

[ossi]

nobody's arguing about defaults, nor about how many users might hypothetically find it useful.

anyway, there is a way to make it saf: explicitly declare the shell in the menu entry. the string would be a key to the quoting rules (a fixed set, like used for the subshell prompt magic), and simultaneously the executable name (to be looked up in PATH).
of course, a bit more effort than hacking in an env variable, but very flexible, and without the risks.

[marcelpaulo]

anyway, there is a way to make it saf: explicitly declare the shell in the menu entry

You're right, I had tried that before posting here. But it doesn't work as expected. To reproduce it, for instance, create a user menu entry like:

0   deleteme
    #!/bin/bash
    [[ $SHELL == /bin/bash ]] && echo "I'm running bash"

The result is:

paulo@monk:~/stage$  /bin/sh /tmp/mc-paulo/mcusrA1GBWX
/tmp/mc-paulo/mcusrA1GBWX: 3: /tmp/mc-paulo/mcusrA1GBWX: [[: not found

Here on Xubuntu 14.10, sh symlinks to dash:

paulo@monk:~$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Nov 25 10:16 /bin/sh -> dash

and it seems that dash doesn't interpret shebang sequences. I don't know if symlinking sh to bash won't break the system.

[marcelpaulo]

Found ​here a good explanation why preceding the menu entry commands with:

#!/bin/bash

won't work. In short: if the interpreter is explicitly invoked in the command line (as mc invokes sh), exec() won't look for it in the shebang line. Therefore, in the example I mentioned, sh (dash actually) will be run and treat #!/bin/bash as a comment.

[ossi]

well, that's obviously the status quo, but it doesn't sound exactly like rocket science to add a simple shebang comment parser.

fwiw, i originally thought about adding some kind of separate option like the condition lines, so it would look like

= t f
! bash
F Foo it
 ...

but shebang parsing might be actually more natural.

[marcelpaulo]

fwiw, i originally thought about adding some kind of separate option like the condition lines, so it would look like

= t f
! bash
F Foo it
 ...

Apologies, I misread you.