If you run mc -F you'll see there are [System data] config directory and [User data] config directory

[System data]

Config directory: /etc/mc/

[User data]

Config directory: /home/<username>/.config/mc/

First is system-wide, the second is User specific.

The second one seems to be dependent on user's home location; in other words, it is bound to it. That means if you want to (temporarily) start mc with an alternate config as the same user you cannot do it w/o changing (and exporting) the HOME variable prior to it. This 'Changing-HOME-prior-to start' workaround, though does the trick, is hardly acceptable, as it well... does modify the user HOME.

Do you think there is a way to either

  1. Change the user config dir dynamically before the mc starts (command line option would be the most appropriate thing, but it does not seem to be there)

  2. Restore 'natural' HOME for user just after mc started, if changing HOME before is the only way to change user dir location

mc instances configured differently must not interfere each other if running simultaneously.

up vote 10 down vote accepted

That turned out to be simpler as one might think. MC_HOME variable can be set to alternative path prior to starting mc. Man pages are not something you can find the answer right away =)

here's how it works: - usual way

[jsmith@wstation5 ~]$ mc -F
Root directory: /home/jsmith

[System data]
<skipped>

[User data]
    Config directory: /home/jsmith/.config/mc/
    Data directory:   /home/jsmith/.local/share/mc/
        skins:          /home/jsmith/.local/share/mc/skins/
        extfs.d:        /home/jsmith/.local/share/mc/extfs.d/
        fish:           /home/jsmith/.local/share/mc/fish/
        mcedit macros:  /home/jsmith/.local/share/mc/mc.macros
        mcedit external macros: /home/jsmith/.local/share/mc/mcedit/macros.d/macro.*
    Cache directory:  /home/jsmith/.cache/mc/

and the alternative way:

[jsmith@wstation5 ~]$ MC_HOME=/tmp/MCHOME mc -F
Root directory: /tmp/MCHOME

[System data]
<skipped>    

[User data]
    Config directory: /tmp/MCHOME/.config/mc/
    Data directory:   /tmp/MCHOME/.local/share/mc/
        skins:          /tmp/MCHOME/.local/share/mc/skins/
        extfs.d:        /tmp/MCHOME/.local/share/mc/extfs.d/
        fish:           /tmp/MCHOME/.local/share/mc/fish/
        mcedit macros:  /tmp/MCHOME/.local/share/mc/mc.macros
        mcedit external macros: /tmp/MCHOME/.local/share/mc/mcedit/macros.d/macro.*
    Cache directory:  /tmp/MCHOME/.cache/mc/

Use case of this feature:

You have to share the same user name on remote server (access can be distiguished by rsa keys) and want to use your favorite mc configration w/o overwritting it. Concurrent sessions do not interfere each other.

This works well as a part of sshrc-approach described in https://github.com/Russell91/sshrc

  • A small drawback of this solution: if you set MC_HOME to a directory different from your usual HOME, mc will ignore the content of your usual ~/.bashrc so, for example, your custom aliases defined in that file won't work anymore. Workaround: add a symlink to your ~/.bashrc into the new MC_HOME directory – Cri Sep 5 '16 at 10:26

If you mean, you want to be able to run two instances of mc as the same user at the same time with different config directories, as far as I can tell you can't. The path is hardcoded.

However, if you mean, you want to be able to switch which config directory is being used, here's an idea (tested, works). You probably want to do it without mc running:

  • Create a directory $HOME/mc_conf, with a subdirectory, one.
  • Move the contents of $HOME/.config/mc into the $HOME/mc_conf/one subdirectory
  • Duplicate the one directory as $HOME/mc_conf/two.
  • Create a script, $HOME/bin/switch_mc:

    #!/bin/bash
    
    configBase=$HOME/mc_conf
    linkPath=$HOME/.config/mc
    
    if [ -z $1 ] || [ ! -e "$configBase/$1" ]; then
        echo "Valid subdirecory name required."
        exit 1
    fi
    
    killall mc
    rm $linkPath
    ln -sv $configBase/$1 $linkPath  
    
  • Run this, switch_mc one. rm will bark about no such file, that doesn't matter.

Hopefully it's clear what's happening there -- this sets a the config directory path as a symlink. Whatever configuration changes you now make and save will be int the one directory. You can then exit and switch_mc two, reverting to the old config, then start mc again, make changes and save them, etc.

You could get away with removing the killall mc and playing around; the configuration stuff is in the ini file, which is read at start-up (so you can't switch on the fly this way). It's then not touched until exit unless you "Save setup", but at exit it may be overwritten, so the danger here is that you erase something you did earlier or outside of the running instance.

  • that works indeed, your idea is pretty clear, thank you for your time However my idea was to be able run diffrently configured mc's under the same account not interfering each other. I should have specified that in my question. the path to config dir is in fact hardcoded, but it is hardcoded RELATIVELY to user's home dir, that is the value of $HOME, thus changing it befrore mc start DOES change the config dir location - I've checked that. the drawback is $HOME stays changed as long as mc runs, which could be resolved if mc had a kind of startup hook to put restore to original HOME into – Tagwint Dec 18 '14 at 16:52
  • I've extended my original q with 'same time' condition - it did not fit in my prev comment size limitation – Tagwint Dec 18 '14 at 17:17

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.