Aliasy Bash powinny znajdować się w plikach .bash_aliaseslub .bashrcw poszczególnych katalogach domowych. Jeśli musisz utworzyć globalne aliasy bash, mogą one wejść /etc/bash.bashrc, ale często najlepiej po prostu dodać je do plików .bash_aliaseslub .bashrc, /etc/skelaby zostały odziedziczone przez nowo utworzonych użytkowników.
Jest praktycznie zawsze źle zdefiniować alias ww .profile, .bash_profilelub /etc/profile.
Aby zrozumieć, dlaczego, należy zrozumieć, w jakich okolicznościach uruchamiane są polecenia z każdego z tych plików . Istnieją nieporozumienia na ten temat, które omówię poniżej.
Chociaż chcesz zdefiniować aliasy dla wielu użytkowników, powinieneś znać sposób ich definiowania dla poszczególnych użytkowników, abyś mógł wybrać najlepszą metodę robienia tego, czego potrzebujesz.
Aliasy dla użytkowników indywidualnych
Zwłaszcza jeśli używasz GUI, większość swoich interaktywnych muszli są prawdopodobnie bez logowania muszle. Nawet jeśli nigdy nie używać GUI, prawdopodobnie nadal korzystać bez logowania muszle z pewną częstotliwością. Będziesz chciał, aby twoje aliasy działały w tych powłokach.
Zwłaszcza jeśli kiedykolwiek logujesz się nie graficznie w wirtualnej konsoli lub za pośrednictwem SSH , prawdopodobnie używasz czasem powłok logowania. Więc chcesz, aby twoje aliasy działały również w interaktywnych powłokach logowania.
Po uruchomieniu interaktywnej powłoki, która nie jest zalogowana , źródło .bashrcznajduje się w katalogu osobistym użytkownika. Domyślnie w Ubuntu, każdy użytkownik .bashrcsam pobiera źródła .bash_aliases, jeśli istnieje.
- Do źródła plik jest przyczyną jego zawartość do uruchomienia w bieżącej powłoki. Zmiany w środowisku powłoki wprowadzone w źródłowym pliku są utrzymywane nawet po uruchomieniu wszystkich poleceń w pliku.
Czytanie komentarzy w domyślnej wersji Ubuntu .bashrcujawnia, że oficjalnie zamierzone jest użycie aliasu w .bashrclub .bash_aliases. .bashrczawiera już niektóre definicje aliasów (uruchom, grep '^[[:blank:]]*alias' ~/.bashrcaby je zobaczyć) i zawiera wyraźne porady na temat tego, gdzie umieścić nowe takie definicje:
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
Ale co z interaktywnymi powłokami logowania ? Zamiast .bashrcźródła logowania do powłoki .profile.
- ... Jeśli nie
.bash_loginistnieje, to zamiast tego jest pozyskiwany.
- ... Jeśli nie
.bash_profileistnieje, to zamiast tego jest pozyskiwany.
Jednak dobrą wiadomością jest to, że domyślnie w Ubuntu polecenia w .bashrcbędą również działać w interaktywnych powłokach logowania, ponieważ domyślnie .profilesprawdza, czy bieżąca powłoka to bash (a jeśli .bashrcistnieje), a jeśli tak, źródła .bashrc:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
Sugeruję, aby użytkownicy definiowali nowe aliasy bash .bash_aliasesw swoich katalogach domowych (tworząc je, jeśli jeszcze nie istnieją). Jest to szczególnie czysty i prosty sposób, aby definicje aliasów były trwałe na poziomie użytkownika.
Aliasy nie powinny być definiowane w,.profile ponieważ pozostałyby niezdefiniowane w powłokach niezalogowanych. W przeciwieństwie do większości środowiska powłoki bash, aliasy nie są eksportowane do powłok potomnych:
ek@Io:~$ alias hi='echo "Greetings, $USER!"'
ek@Io:~$ hi
Greetings, ek!
ek@Io:~$ bash
ek@Io:~$ hi
hi: command not found
W szczególności domyślnie większość środowisk .profilegraficznych korzysta z logowania graficznego, ale:
- Nie jest to konieczne przez powłokę bash, więc definicje aliasów mogą nawet nie zostać przetworzone, a co ważniejsze
- nawet jeśli definicje aliasów są przetwarzane, nie są one przekazywane do procesów potomnych . W szczególności nie są one przekazywane do powłok utworzonych przez otwarcie okna terminala!
Aliasy nie powinny być definiowane w .bash_profile(lub .bash_login) z tego samego powodu, ale także z innego powodu. Naiwne tworzenie jednego z tych plików i umieszczanie w nim tylko definicji aliasów uniemożliwia .profileuruchomienie dowolnego kodu !
W sytuacjach, w których .bash_profilelub .bash_loginnaprawdę jest przydatny, zwykle .profilegdzieś w nich jest jedno źródło , co rozwiązuje ten problem. (Wtedy jedynym problemem jest to, że podobnie jak w przypadku .profiledefiniowania aliasów w .bash_profilelub .bash_loginnie działa poprawnie).
Aliasy dla nowych indywidualnych użytkowników, automatycznie
Kiedy tworzone jest konto użytkownika typu, który ma reprezentować prawdziwą istotę ludzką, zwykle tworzony jest nowy katalog, który ma służyć jako katalog domowy. Zawartość /etc/skeljest następnie kopiowana do katalogu domowego. W ten sposób wielu użytkowników zaczyna od podobnych plików konfiguracyjnych w swoich katalogach domowych. W Ubuntu, obejmuje .profile, .bashrci kilka innych plików.
Aby zmienić zdefiniowane aliasy dla nowych użytkowników, możesz je po prostu wstawić /etc/skel/.bash_aliases(musisz je utworzyć) lub /etc/skel/.bashrc.
Jeśli edytujesz już istniejący plik, /etc/skelmożesz najpierw wykonać kopię zapasową - ale nie powinieneś umieszczać kopii zapasowej, w /etc/skelprzeciwnym razie zostanie ona również skopiowana do katalogów domowych nowych użytkowników.
Jest to prawdopodobnie najlepszy sposób na dodanie nowych aliasów dla wielu użytkowników. Obecni użytkownicy mogą po prostu samodzielnie dodawać aliasy. Jeśli zdefiniujesz aliasy /etc/skel/.bash_aliases, możesz po prostu przekierować je do tego pliku, który mogą skopiować do swoich katalogów domowych (lub dodać do własnego .bash_aliasespliku niestandardowego ).
Nie jest łatwo zdefiniować alias. Ponadto aliasy nie są wyjątkowo odporne ; działają tylko w szczególnych okolicznościach. Jeśli musisz utworzyć nowe polecenie, które będzie działać przez cały czas, dla wszystkich nie powinieneś implementować tego polecenia jako aliasu. I nie możesz skutecznie wymusić aliasów na użytkownikach, którzy ich nie chcą - mogą po prostu unaliasich.
Globalne aliasy dla wszystkich użytkowników
Choć radzę unikać takiego podejścia, to można zdefiniować aliasy w tym globalnym /etc/bash.bashrc pliku. Zostaną one następnie zdefiniowane zarówno dla interaktywnych powłok bez logowania, jak i dla interaktywnych powłok logowania. Powodem jest to, że zanim pliki w katalogu osobistym użytkownika zostaną pozyskane:
- Powłoki logowania (i tylko powłoki logowania i inne procesy zachowujące się jak powłoki logowania) uruchamiają polecenia
/etc/profileautomatycznie.
- Tylko powłoki niezalogowane uruchamiają polecenia
/etc/bash.bashrcautomatycznie, ale
- Domyślnie Ubuntu
/etc/profilesprawdza, czy działająca powłoka to bash (a jeśli /etc/bash.bashrcistnieje), a jeśli tak, to źródła /etc/bash.bashrc.
Jest to analogiczne do tego, w jaki sposób domyślny użytkownik .profilepozyskuje użytkownika, .bashrcjeśli powłoka jest bash (jak opisano powyżej).
Oto jak wygląda rzeczywisty kod tego ustawienia domyślnego /etc/profile:
if [ "$PS1" ]; then
if [ "$BASH" ] && [ "$BASH" != "/bin/sh" ]; then
# The file bash.bashrc already sets the default PS1.
# PS1='\h:\w\$ '
if [ -f /etc/bash.bashrc ]; then
. /etc/bash.bashrc
fi
else
if [ "`id -u`" -eq 0 ]; then
PS1='# '
else
PS1='$ '
fi
fi
fi
Ten blok wykonuje również inne zadania. W szczególności zewnętrzna ifsprawdza, czy powłoka może być interaktywna (sprawdzając, czy tekst zachęty nie jest pusty), a następnie sprawdza, czy bieżąca powłoka to bash i źródła, /etc/bash.bashrcjeśli jest, a jeśli nie, to działa w przypadku bash , jest już zrobione w /etc/bash.bashrc.
Należy nie definiują globalne aliasów /etc/profiledla samych użytkowników powód nie powinien definiować ich w swoich lokalnych .profiles: jeśli nie zostaną one zdefiniowane tylko dla powłok zgłoszeniowych, a nie dla ich muszli potomnych.
Na koniec zauważ, że w przeciwieństwie do domyślnego użytkownika .bashrc, domyślny /etc/bash.bashrcplik nie zawiera niczego na temat aliasów. Dawanie użytkownikom aliasów w pliku, w którym nie mogą ich edytować ani wyłączać, jest dość niezwykłe. (Oczywiście, nadal może to zrobić, poprzez nadpisanie ich definicje we własnym lokalnym .bashrc, .bash_aliaseslub gdzie indziej).
Dalsza lektura