Obecnie nie ma bezpośredniego sposobu, aby zresetować powiązanie klucza z domyślnym; inicjalizacja domyślnych powiązań (in key_bindings_init()
) odbywa się raz, gdy serwer tmux uruchamia się po raz pierwszy (in server_start()
), i nie ma mechanizmu do resetowania pojedynczego klucza.
W pożądanym scenariuszu, w którym chcesz, aby proces pozyskiwania pliku konfiguracyjnego ponownie ustanowił domyślne powiązanie, które zostało wcześniej zastąpione niestandardowym powiązaniem, które zostało później usunięte z pliku konfiguracyjnego, opracowana metoda jest rozsądna (choć niestety pełna): unbind-key -a
, następnie przywróć wszystkie „domyślne” wiązania, a następnie utwórz własne wiązania (niektóre z nich mogą zastąpić „domyślne”).
Bieżące powiązania serwera można wyodrębnić za pomocą list-keys
polecenia * ; może to pomóc w generowaniu / utrzymywaniu proponowanego .tmux.reset.conf
pliku, ale potrzebujesz sposobu na wyodrębnienie domyślnych powiązań, a nie bieżących .
* Istnieją sytuacje, w których dane wyjściowe list-keys
nie są obecnie bezpośrednio użyteczne: wiązanie średnika wymaga, aby jego średnik uciekł odwrotnym ukośnikiem, aby zapobiec interpretacji go jako separatora poleceń tmux oraz wszelkich powiązań, które miały argumenty wykorzystujące podwójne cudzysłowy wewnątrz pojedynczego cytaty (żadne z domyślnych powiązań nie są takie) pojawią się jako podwójne cudzysłowy wewnątrz podwójnego qoutes.
Aby uzyskać domyślne powiązania, potrzebujesz tymczasowego serwera z minimalną konfiguracją (tj. Bez niestandardowych powiązań), abyś mógł przechwytywać jego list-keys
dane wyjściowe. Nie ma ograniczeń co do liczby serwerów Tmux , które możesz uruchomić, ale każdy z nich musi używać innej nazwy ścieżki gniazda; te -L
i -S
tmux opcje mogą być wykorzystane, aby określić nazwę gniazda (w $TMPDIR/tmux-$UID
lub pełną ścieżkę gniazdo tak, to do rozmowy (lub uruchomić) nowy serwer o nazwie gniazda. temp
, należy użyć tego:
tmux -L temp …
Aby upewnić się, że nie używa twojego .tmux.conf
, możesz -f
powiedzieć mu, aby przeczytał /dev/null
(specjalny plik, który jest zawsze pusty):
tmux -f /dev/null -L temp …
Uwaga : nie uniemożliwia to przetwarzania/etc/tmux.conf
, jeśli taki plik istnieje; ścieżka do tego „pliku konfiguracji systemu” jest zakodowana na stałe i nie ma możliwości ominięcia go (bez łatania kodu).
Zwykle potrzebujesz new-session
polecenia, aby faktycznie uruchomić serwer, ale nie chcemy żadnych sesji, tylko zainicjowany serwer do zapytania. start-server
Komenda właśnie to robi: uruchamia serwer bez tworzenia sesji.
tmux -f /dev/null -L temp start-server …
Teraz wystarczy dołączyć nasze polecenie „zapytanie” ( list-keys
w tym przypadku):
tmux -f /dev/null -L temp start-server \; list-keys
Uwaga : średnik musi być poprzedzony znakiem zapytania lub cudzysłowem, aby powłoka nie traktowała go jako separatora poleceń powłoki, ponieważ chcemy, aby był tmux separatorem poleceń .
Ponieważ nie ma żadnych sesji do utrzymania, serwer zakończy działanie automatycznie po zakończeniu działania list-keys
polecenia.
Możesz więc użyć takiego polecenia, aby wygenerować większość .tmux.reset.conf
bez konieczności tymczasowego usuwania .tmux.conf
pliku (aby zobaczyć tylko domyślne powiązania) i bez konieczności zamykania istniejących serwerów.
Jeśli run-shell
polecenie było synchroniczne, możesz osadzić takie wywołanie w pliku konfiguracyjnym (przechwytywanie do pliku tymczasowego, który następnie przetworzyłbyś source-file
) zamiast mieć plik statyczny (twój .tmux.reset.conf
). Pozwoliłoby to zawsze używać domyślnych powiązań z bieżącej wersji tmux (domyślne wiązania czasami się zmieniają). Niestety, wykonanie run-shell
polecenia jest obecnie asynchroniczne w odniesieniu do kolejnych poleceń (polecenia, które pojawiają się po run-shell
poleceniu, zwykle są uruchamiane, zanim proces spawnowany run-shell
miał szansę zakończyć).