Opción de inicio de la ubicación del directorio de configuración de Midnight Commander

10

Si ejecuta mc -F , verá que hay un directorio de configuración [Datos del sistema] y un directorio de configuración [Datos del usuario]

[Datos de sistema]

Config directory: /etc/mc/

[Datos del usuario]

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

Primero es todo el sistema, el segundo es específico del usuario.

El segundo parece depender de la ubicación de inicio del usuario; en otras palabras, está obligado a ello. Eso significa que si desea (temporalmente) iniciar mc con una configuración alternativa como el mismo usuario, no puede hacerlo sin cambiar (e exporting) la variable HOME antes. Esta solución alternativa 'Changing-HOME-before-to start', aunque hace el truco, no es aceptable, ya que bien ... modifica el usuario HOME.

¿Crees que hay una manera de

  1. Cambie el directorio de configuración del usuario dinámicamente antes de que comience el mc (la opción de línea de comando sería lo más apropiado, pero no parece estar allí)

  2. Restaure HOME "natural" para el usuario justo después de que comience mc, si cambiar HOME antes es la única forma de cambiar la ubicación del directorio de usuario

Las instancias de mc configuradas de manera diferente no deben interferir entre sí si se ejecutan simultáneamente.

mc Tagwint
fuente

Respuestas:

11

Eso resultó ser más simple como uno podría pensar. La variable MC_HOME se puede establecer en una ruta alternativa antes de iniciar mc. Las páginas de manual no son algo en lo que puedas encontrar la respuesta de inmediato =)

así es como funciona: - forma habitual

[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/

y la forma alternativa:

[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/

Caso de uso de esta característica:

Debe compartir el mismo nombre de usuario en el servidor remoto (el acceso puede verse afectado por las teclas rsa) y desea utilizar su configuración de mc favorita sin sobrescribirla. Las sesiones concurrentes no se interfieren entre sí.

Esto funciona bien como parte del enfoque sshrc descrito en https://github.com/Russell91/sshrc

Tagwint
fuente
Un pequeño inconveniente de esta solución: si configura MC_HOME en un directorio diferente de su HOME habitual, mc ignorará el contenido de su ~ / .bashrc habitual, por lo que, por ejemplo, sus alias personalizados definidos en ese archivo ya no funcionarán. Solución alternativa: agregue un enlace simbólico a su ~ / .bashrc en el nuevo directorio MC_HOME
Cri
1

Si quiere decir, desea poder ejecutar dos instancias de mc como el mismo usuario al mismo tiempo con diferentes directorios de configuración, por lo que puedo decir, no puede. El camino está codificado.

Sin embargo, si quiere decir que desea poder cambiar qué directorio de configuración se está utilizando, aquí hay una idea (probada, funciona). Probablemente quieras hacerlo sin ejecutar mc:

  • Crear un directorio $HOME/mc_conf, con un subdirectorio, one.
  • Mover el contenido de $HOME/.config/mcal $HOME/mc_conf/onesubdirectorio
  • Duplicar el onedirectorio como $HOME/mc_conf/two.

  • Crea un 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

  • Ejecutar este, switch_mc one. rmladrará sobre tal archivo, eso no importa.

Esperemos que esté claro lo que está sucediendo allí: esto establece la ruta del directorio de configuración como un enlace simbólico. Cualquier cambio de configuración que haga y guarde ahora será int en el onedirectorio. Luego puede salir y switch_mc twovolver a la configuración anterior, luego iniciar mc nuevamente, realizar cambios y guardarlos, etc.

Podrías salirte con la eliminación killall mcy jugar; el material de configuración está en el iniarchivo, que se lee al inicio (por lo que no puede activarlo al instante). Luego no se toca hasta la salida a menos que "Guarde la configuración", pero al salir puede sobrescribirse, por lo que el peligro aquí es que borre algo que hizo antes o fuera de la instancia en ejecución.

encerrada dorada
fuente
eso funciona de hecho, su idea es bastante clara, gracias por su tiempo. Sin embargo, mi idea era poder ejecutar mc configurados de manera diferente bajo la misma cuenta sin interferir entre sí. Debería haber especificado eso en mi pregunta. la ruta al directorio de configuración de hecho está codificada, pero está codificada RELATIVAMENTE al directorio de inicio del usuario, ese es el valor de $ HOME, por lo que cambiarlo antes de iniciar mc cambia la ubicación del directorio de configuración. Lo he comprobado. el inconveniente es que $ HOME permanece modificado mientras se ejecuta mc, lo que podría resolverse si mc tuviera una especie de enlace de inicio para poner la restauración en HOME original
Tagwint
Extendí mi q original con la condición de 'mismo tiempo'; no encajaba en mi limitación de tamaño de comentario anterior
Tagwint