MC_DATADIR doesn't override DATADIR (only SYSCONFDIR)

[Vrihub]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

GNU Midnight Commander 3e8800ead
Built with GLib 2.84.4 (using GLib 2.84.4)
Built with S-Lang 2.3.3 and terminfo database (using S-Lang 2.3.3)
Built with libssh2 1.11.1
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 ext2fs attributes support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;

Operating system

Linux 6.12.43+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.43-1 (2025-08-27) x86_64 GNU/Linux

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

Run:

MC_DATADIR=DATA MC_PROFILE_ROOT=ROOT mc -F

Expected behavior

Home directory: homesweethome
Profile root directory: ROOT
 
[System data]
    Config directory: DATA
    Data directory: DATA
...etc...

Actual behavior

Home directory: homesweethome
Profile root directory: ROOT
 
[System data]
    Config directory: DATA
    Data directory:   /usr/local/share/mc/
...etc...

But man mc says:

They are also affected by the MC_DATADIR environment variable. If it's set, its value is used instead of /usr/local/share/mc in the paths below

Reason: currently MC_DATADIR only overrides SYSCONFDIR; it should also override DATADIR.

Suggested fix (tested, works for me): modify OS_Setup() in src/main.c like this:

OS_Setup (void)
{
    mc_shell_init ();
 
    // The MC_DATADIR env variable allows overriding SYSCONFDIR and DATADIR
    const char *datadir_env = g_getenv ("MC_DATADIR");
 
    if (datadir_env != NULL)
    {
        mc_global.sysconfig_dir = g_strdup (datadir_env);
        mc_global.share_data_dir = g_strdup (datadir_env);
    }
    else
    {
        mc_global.sysconfig_dir = g_strdup (SYSCONFDIR);
        mc_global.share_data_dir = g_strdup (DATADIR);
    }
}

I can submit a PR if you agree with the solution.

Additional context

No response

[zyv]

I don't like the idea of making it possible to override the paths to package components at runtime. Apparently, it was added in #2738, but I don't know why it was done. Nobody seemed to ask for it.

However, if such a possibility exists, it should indeed work reasonably. Currently, the variable is called MC_DATADIR and it is used to override sysconfdir, so it should be actually called MC_SYSCONFDIR.

I agree with you that the current state doesn't seem logical, but I disagree with the proposed solution. You suggest keeping the variable name and using it to override the values of both datadir and sysconfdir. Why would you want to do this? It doesn't make any sense to me, and the two variables don't have anything to do with each other.

To figure out a proper solution (other than just removing this facility), I think it would be nice to understand:

1. Why would you want to override sysconfdir in the first place?
2. Why would you want to override datadir (and use the same value as for sysconfdir)?
3. Why don’t you want to override libexecdir as well?
4. Why would you want to do it at runtime and not during compilation?

---

The meaning of the variables is described in the GNU Coding Standards:

https://www.gnu.org/prep/standards/html_node/Directory-Variables.html

sysconfdir - The directory for installing read-only data files that pertain to a single machine–that is to say, files for configuring a host. [...] This directory should normally be /usr/local/etc.

datadir - The directory for installing idiosyncratic read-only architecture-independent data files for this program. This is usually the same place as ‘datarootdir’, but we use the two separate variables so that you can move these program-specific files without altering the location for Info files, man pages, etc.

This should normally be /usr/local/share. The definition of ‘datadir’ is the same for all packages, so you should install your data in a subdirectory thereof, such as /usr/local/share/package-name/.

libexecdir - The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be /usr/local/libexec. The definition of ‘libexecdir’ is the same for all packages, so you should install your data in a subdirectory thereof, such as /usr/local/libexec/package-name.

In my case:

% mc -F                                     
Home directory: /Users/zaytsev
Profile root directory: /Users/zaytsev

[System data]
    Config directory: /opt/homebrew/Cellar/midnight-commander/4.8.33/etc/mc/
    Data directory:   /opt/homebrew/Cellar/midnight-commander/4.8.33/share/mc/
    File extension handlers: /opt/homebrew/Cellar/midnight-commander/4.8.33/libexec/mc/ext.d/
    VFS plugins and scripts: /opt/homebrew/Cellar/midnight-commander/4.8.33/libexec/mc/
	extfs.d:        /opt/homebrew/Cellar/midnight-commander/4.8.33/libexec/mc/extfs.d/
	shell:          /opt/homebrew/Cellar/midnight-commander/4.8.33/libexec/mc/shell/

[Vrihub]

Thanks for the detailed explanation.

I noticed this bug...ehm thing while compiling mc and executing the mc binary directly from the /src dir, without make installing (actually I execute it via a shell wrapper which sets a proper MC_ROOT_DIR). I noticed that the online help wasn't working (mc couldn't find /usr/local/share/mc/help/mc.hlp), so I read the man page and found out that you can use MC_DATADIR to override /usr/local/share/mc/, but this was not working.

Now, I guess the proper way to run the locally compiled mc is by running make install, but I'm lazy and I'm not entirely sure that installing in /usr/local/ avoids all possible conflicts with my system's mc installed from the Debian package and allows testing the locally compiled mc in isolation, please let me know if I'm wrong, or point me to the right way to do that, thanks.

Anyway, we still have a conflict between what is said in the man page (which I assumed was the intended behaviour) and what mc actually does, which brings to your questions:

1. Why would you want to override sysconfdir in the first place?

I can't think of any reason, since you can already set up customized configuration profiles using MC_PROFILE_ROOT.

2. Why would you want to override datadir (and use the same value as for sysconfdir)?

See my example above, but I admit it's only an ugly hack used to workaround a problem I encountered in my unorthodox way to run the locally compiled mc without installing it.

3. Why don’t you want to override libexecdir as well?
4. Why would you want to do it at runtime and not during compilation?

I'm not qualified to answer these questions either, common sense would suggest against overriding compile-time variables at runtime, maybe it can be beneficial in some testing situations (allowing to make some changes at runtime, withouth having to re-compile and re-install)?

You suggest keeping the variable name and using it to override the values of both datadir and sysconfdir. Why would you want to do this? It doesn't make any sense to me, and the two variables don't have anything to do with each other.

Well, I assumed that allowing overriding sysconfdir (as implemented in main.c) and datadir (as stated in the man page, but not implemented) was intended behaviour and I just proposed the minimal change to resolve the conflict, without questioning the original intentions.

So I agree we (er... you maintainers) should first decide if the whole overriding idea is desirable (sorry I don't have much to contribute to the debate), then resolve the conflict between code and man.

[egmontkob]

common sense would suggest against overriding compile-time variables at runtime

I agree. I wouldn't mind getting rid of this env var (I never used it).

I agree it's only useful for debugging on some rare occasions, but a ./configure --prefix=/home/username/mc-install-dir && make && make install should always give you a proper installation.

and I'm not entirely sure that installing in /usr/local/ avoids all possible conflicts with my system's mc installed from the Debian package and allows testing the locally compiled mc in isolation

This should work safely, I'm quite certain. The default of ./configure is to install everything under /usr/local, even the etc dir is /usr/local/etc, not /etc as used by your Debian package. One should not look for files in the other's installation, and vice versa.

I have a recent-ish default installation under /usr/local, and most of the time I just test a change to the binary by running ./src/mc, no installation. It only fails if the change relies on a change in one of the installed files (e.g. new skin), but then again I'm only an installation away from testing it properly.

I doubt typical packages have a way to runtime configure the global paths, and I don't see mc being special here with additional needs.

It could be of a tiny help for some contributors (not me) while debugging, but IMHO it's something easy to live without.

[zyv]

I see, thank you for the details. This clears up where you are coming from.

Now, I guess the proper way to run the locally compiled mc is by running make install, but I'm lazy and I'm not entirely sure that installing in /usr/local/ avoids all possible conflicts

The proper way (as our verbose documentation on building GNU packages, which has nothing to do with mc, explains) is to configure with a custom prefix and install there like ./configure --prefix=$(pwd)/install && make install.

1. Why would you want to override sysconfdir in the first place?

I can't think of any reason, since you can already set up customized configuration profiles using MC_PROFILE_ROOT.

Yes, this is also how I understand the use case for MC_PROFILE_ROOT, and I believe that it should stay.

2. Why would you want to override datadir (and use the same value as for sysconfdir)?

See my example above, but I admit it's only an ugly hack used to workaround a problem I encountered in my unorthodox way to run the locally compiled mc without installing it.

I see, so here you should actually use a custom prefix instead.

So I agree we (er... you maintainers) should first decide if the whole overriding idea is desirable (sorry I don't have much to contribute to the debate), then resolve the conflict between code and man.

@mc-worker, do you agree with removing MC_DATADIR? Are there any special reasons why it was introduced?

[Vrihub]

I agree it's only useful for debugging on some rare occasions, but a ./configure --prefix=/home/username/mc-install-dir && make && make install should always give you a proper installation.
...
This should work safely, I'm quite certain. The default of ./configure is to install everything under /usr/local, even the etc dir is /usr/local/etc, not /etc as used by your Debian package. One should not look for files in the other's installation, and vice versa.
...
The proper way (as our verbose documentation on building GNU packages, which has nothing to do with mc, explains) is to configure with a custom prefix and install there like ./configure --prefix=$(pwd)/install && make install.

Thanks for the confirmation, I seemed to remember this is the case, but it's been a while since I haven't played with these building tools and I forgot quite a bit of details.

Yes, this is also how I understand the use case for MC_PROFILE_ROOT, and I believe that it should stay.

Yes, MC_PROFILE_ROOT is very useful and it should definitely stay (I'm actually thinking of expanding its explanation in the man page and adding an entry about it in the FAQ and/or the hints file, as part of a future PR about improving the documentation).

[egmontkob]

Sorry for my ignorance, what is MC_PROFILE_ROOT?

Isn't it something that should be replaced by XDG_WHATEVER?

[zyv]

Sorry for my ignorance, what is MC_PROFILE_ROOT?

https://source.midnight-commander.org/man/mc.html#FILES

Isn't it something that should be replaced by XDG_WHATEVER?

My understanding of the current state is that it works like this:

1. If it's not specified, then XDG variables are respected: https://specifications.freedesktop.org/basedir/latest/
2. If it is specified, then everything is pooled together like in the good old times.

I don't think there is an XDG variable that has a meaning of a prefix.

[egmontkob]

So it's a convenience shortcut (as well as a legacy compatibility option) to set multiple XDG_* at once. Makes sense. Thx!