Actualmente no existe una forma directa de restablecer el enlace de una clave a su valor predeterminado; la inicialización de los enlaces predeterminados (in key_bindings_init()
) se realiza una vez cuando el servidor tmux se inicia por primera vez (in server_start()
), y no existe un mecanismo para restablecer una sola clave.
Para su escenario deseado en el que desea el acto de la compra de componentes del archivo de configuración para restablecer una unión que fue anulada previamente por un enlace que desde entonces ha sido borrado de su archivo de configuración personalizado predeterminado, el método que ideó es razonable (aunque por desgracia detallado): unbind-key -a
, luego restablezca todos los enlaces "predeterminados", luego establezca sus enlaces personalizados (algunos de los cuales podrían anular un enlace "predeterminado").
Los enlaces actuales de un servidor se pueden extraer con el list-keys
comando * ; esto puede ayudar a generar / mantener su .tmux.reset.conf
archivo propuesto , pero necesita una forma de extraer los enlaces predeterminados , no los enlaces actuales .
* Hay algunas situaciones en las que la salida de list-keys
actualmente no se puede usar directamente: el enlace para punto y coma necesita que su punto y coma se escape con una barra diagonal inversa para evitar que se interprete como un separador de comando tmux , y cualquier enlace que tenga argumentos que usen comillas dobles dentro de comillas simples las comillas (ninguno de los enlaces predeterminados son así) aparecerán como comillas dobles dentro de dobles qoutes.
Para obtener los enlaces predeterminados, necesita un servidor temporal con una configuración mínima (es decir, sin enlaces personalizados) para poder capturar su list-keys
salida. No hay límite para la cantidad de servidores tmux que puede ejecutar, pero cada uno debe usar un nombre de ruta de socket diferente; las opciones -L
y -S
tmux se pueden usar para especificar un nombre de socket (en $TMPDIR/tmux-$UID
o nombre de ruta de socket completo. Por lo tanto, para hablar (o iniciar) un nuevo servidor en un socket llamado temp
, usaría esto:
tmux -L temp …
Para asegurarte de que no usa tu .tmux.conf
, usas -f
para decirle que lea /dev/null
(un archivo especial que siempre está vacío):
tmux -f /dev/null -L temp …
Nota : esto no impide el procesamiento de /etc/tmux.conf
, si existe dicho archivo; la ruta a este "archivo de configuración del sistema" está codificada y no hay opción para omitirla (salvo parchear el código).
Normalmente, necesita un new-session
comando para iniciar realmente el servidor, pero no queremos ninguna sesión, solo un servidor inicializado para consultar. El start-server
comando hace exactamente eso: inicia un servidor sin crear ninguna sesión.
tmux -f /dev/null -L temp start-server …
Ahora, solo necesitamos agregar nuestro comando "query" ( list-keys
en este caso):
tmux -f /dev/null -L temp start-server \; list-keys
Nota : el punto y coma debe ser escapado o citado para evitar que el shell lo trate como un separador de comandos de shell, ya que queremos que sea un separador de comandos tmux .
Como no hay sesiones que mantener, el servidor se cerrará automáticamente cuando termine de ejecutar el list-keys
comando.
Por lo tanto, puede usar un comando como este para generar la mayor parte de su contenido .tmux.reset.conf
sin tener que preocuparse por eliminar temporalmente su .tmux.conf
archivo (para permitirle ver solo los enlaces predeterminados) y sin tener que cerrar ningún servidor existente.
Si el run-shell
comando fuera síncrono, podría incrustar una llamada como esta en su archivo de configuración (capturar en un archivo temporal con el que luego procesaría source-file
) en lugar de tener un archivo estático (su .tmux.reset.conf
). Eso le permitiría usar siempre los enlaces predeterminados de su versión actual de tmux (los enlaces predeterminados cambian ocasionalmente). Por desgracia, la finalización del run-shell
comando es actualmente asíncrona con respecto a los comandos posteriores (los comandos que vienen después de un run-shell
comando generalmente se ejecutarán antes de que el proceso generado run-shell
haya tenido la oportunidad de finalizar).