Zasadniczo ustawiam zmienne środowiskowe VISUAL
i EDITOR
środowiskowe na to samo, ale jaka jest różnica? Dlaczego miałbym je ustawiać inaczej? Dlaczego podczas tworzenia aplikacji powinienem patrzeć VISUAL
przedtem EDITOR
lub na odwrót?
Zasadniczo ustawiam zmienne środowiskowe VISUAL
i EDITOR
środowiskowe na to samo, ale jaka jest różnica? Dlaczego miałbym je ustawiać inaczej? Dlaczego podczas tworzenia aplikacji powinienem patrzeć VISUAL
przedtem EDITOR
lub na odwrót?
Odpowiedzi:
EDITOR
Redaktor powinien być w stanie pracować bez użycia „Zaawansowane” terminala funkcjonalności (jak stary ed
lub ex
trybu vi
). Użyto go na terminalach teletype.
VISUAL
Edytor może być pełny ekran jako redaktor vi
lub emacs
.
Np. Jeśli wywołasz edytor przez bash (za pomocą C-x C-e
), bash spróbuje najpierw VISUAL
edytora, a następnie, jeśli się VISUAL
nie powiedzie (ponieważ terminal nie obsługuje edytora pełnoekranowego), spróbuje EDITOR
.
W dzisiejszych czasach możesz pozostawić EDITOR
nieuzbrojony lub ustawić go na vi -e
.
ed
i tym podobne nie są zbyt popularne, więc uważam, że po prostu zignoruj VISUAL
i użyj EDITOR
.
C-x C-e
w bash. Bardzo przydatny.
EDITOR
to za mało, np. Dla git
Ubuntu 12.04. Bez VISUAL
ustawienia git
ignoruje EDITOR
i po prostu używa nano
(domyślnie jest to kompilacja).
ed
. Kiedy powstały edytory z GUI - a przez GUI mam na myśli GUI CLI (vim, emacs itp. - Think ncurses), a nie GUI środowiska graficznego - proces edycji zmienił się diametralnie, więc pojawiła się potrzeba innej zmiennej. W tym kontekście edytory GUI CLI i środowiska graficznego są mniej więcej takie same, więc możesz ustawić VISUAL na jeden z nich; jednak EDYTOR przeznaczony jest do zasadniczo innego przepływu pracy. Oczywiście to wszystko jest historyczne. Obecnie nikt nie używa ed.
Przyjęta odpowiedź jest prawdopodobnie dobrym, krótkim traktowaniem, ale będzie to próba głębszego zbadania, kiedy różnica między VISUAL a EDITOREM może nadal mieć znaczenie (w oparciu o odpowiedź Adama Katza ).
Specyfikacja POSIX wciąż rozróżnia edytory trybu wizualnego i edytory liniowe. To naprawdę miało znaczenie w czasach, gdy pozycjonowanie kursora nad połączeniami szeregowymi było trudne (szczególnie ze względu na szybkość połączenia szeregowego). Artykuł w Wikipedii dotyczący vi zawiera przydatne informacje na temat rozróżnienia między vi (edytor trybu wizualnego) i ex (edytor linii). Jeśli zagłębisz się wystarczająco głęboko w badania, znajdziesz sekcję „RATIONALE” specyfikacji „ex” , która daje powód, dla którego wciąż wyróżnia się to w specyfikacji:
Uznaje się, że części vi byłyby trudne, jeśli nie niemożliwe, do zadowalającej implementacji na terminalu w trybie blokowym lub terminalu bez jakiejkolwiek formy adresowania kursora, dlatego nie jest obowiązkowym wymogiem, aby takie funkcje działały na wszystkich terminalach . Jednak intencją jest, aby implementacja vi zapewniała pełny zestaw możliwości na wszystkich terminalach zdolnych do ich obsługi.
Nie potrzebowałem tego, odkąd zrezygnowałem z modemu o szybkości 300 bodów, ale mogę sobie wyobrazić, że ludzie, którzy używają wolnych linii szeregowych do łączenia się z systemami wbudowanymi (i / lub za pośrednictwem bardzo dicey połączeń) nadal mogą docenić możliwość wyboru preferowanego trybu linii edytor różni się od edytora „wizualnego”, takiego jak vi. Kody terminali w stylu VT100 w przypadku stratnego, opóźnionego, wąskiego połączenia mogą być „rozdęte” w ograniczonych aplikacjach.
Dla reszty z nas wydaje się, że „poprawną” odpowiedzią wydaje się być „ustaw je jako preferowany edytor”. Dobrym rozwiązaniem może być wybranie tego rozróżnienia dla edytora lokalnego / graficznego (np. Sublime lub gvim) w porównaniu z edytorem okien terminalowych (np. Vi lub emacs), ale prawdopodobnie istnieje wiele starszych powodów, dla których prawdopodobnie nie zadziała tak, jak się spodziewano .
Niektóre narzędzia akceptują tylko EDYTOR, na przykład wbudowana powłoka fc :
-e ENAME select which editor to use. Default is FCEDIT, then EDITOR, then vi
Doszedłem do wniosku, że $VISUAL
to grafika i $EDITOR
linia poleceń. Jeśli nie jest zdefiniowane, cokolwiek szukającego $VISUAL
powinno następnie spróbować $EDITOR
dalej.
( Potrzebne cytowanie: Chciałbym uzyskać odpowiednią dokumentację, może stronę podręcznika lub specyfikację POSIX?)
W tej chwili mam takie rzeczy w mojej ~/.bashrc
i ~/.zshrc
:
EDITOR="$(command -v vim)"
# we have gvim, not in an SSH term, and the X11 display number is under 10
if command -v gvim >/dev/null 2>&1 \
&& [ "$SSH_TTY$DISPLAY" = "${DISPLAY#*:[1-9][0-9]}" ]; then
export VISUAL="$(command -v gvim) -f"
SUDO_EDITOR="$VISUAL"
else
SUDO_EDITOR="$EDITOR"
fi
gvim
bez -f
nie będzie działać z programami, które oczekują, że wprowadzą zmiany. To zdecydowanie obejmuje sudoeditor
( sudo -e
).
Może się to zepsuć, jeśli masz spacje na ścieżce do vima. Jeśli to jest problem, albo zainstaluj go poprawnie, albo rozważ takie dowiązania symboliczne/usr/local/bin/gvim
$VISUAL
zależy od tego, czy masz terminal zdolny do pozycjonowania kursora, a nie od tego, czy masz dostępny system okien.
$DISPLAY
, ale dobrze wiedzieć.
Ponieważ wydaje się, że nie ma żadnych środowisk, w których zawiodłoby vi lub podobne, postanowiłem ustawić VISUAL na coś, co wymaga X WYŚWIETLACZA, a EDYTORA np.
W większości przypadków wydaje mi się to powodować problemy, gdy jakiś program nie używa VISUAL.
$VISUAL
jako fragment powłoki, do którego dołączają nazwę pliku (cytowaną w powłoce), ale niektóre traktują ją jako nazwę pliku wykonywalnego, w którym mogą wyszukiwać lub nie$PATH
. Dlatego najlepiej ustawićVISUAL
(iEDITOR
) pełną ścieżkę do pliku wykonywalnego (który może być skryptem opakowania, jeśli chcesz np. Opcji).