Pozwolicie, że wyraże swoją opinię, albo załużmy nowy temat do dyskusji o bezpieczeństwie ...
Nie wiem czy się zgodzisz, ale czytałem1 jakiś czas temu, że lepiej unikać dziś w nowoczesnych środowiskach stosowania aliasów. Dlaczego?
Ponieważ lepiej napisać niewielki skrypt bash. Plusy skryptu to m. in. łatwa możliwość odnalezienia go w przyszłości w celu edycji lub usunięcia np. poleceniem type czy which. Miejsc gdzie zdefiniowane są natomiast aliasy jest kilka w systemie, zaczynając od zmiennych wbudowanych BASH_ALIASES po pliki /etc/bashrc oraz ~/.bashrc. Jeśli chcemy zlokalizować gdzie jest konkretny alias to pojawia się problem.
Wszystko zależy od systemu, ale ze znalezieniem aliasu nie powinno być problemu, bynajmniej jeśli mówimy o tych robionych przez użytkownika.
Aktywna powłoka bash , więc --> ~/.bashrc ( ewentualnie dla root /root/.bashrc , a nie żadne /etc ! ponieważ przy aktualizacji system nadpisze plik )
SPROSTOWANIE
Przepraszam, jeżeli chodzi o aliasy dla wszystkich użytkowników to chyba masz racje, czyli konfiguracja aliasów będzie w /etc/ ...
( choc mam dylemat ... później dopiszę ... )
============================={
( Ciąg dalszy ...
Nie posiadam pliku /etc/bashrc
$ ls /etc/bashrc
ls: nie ma dostępu do '/etc/bashrc': Nie ma takiego pliku ani katalogu
ale jest /etc/bash.bashrc
$ locate bashrc
/etc/bash.bashrc
/etc/skel/.bashrc
/home/tele/.bashrc
...
Według poradników w intrenecie
/etc/bashrc (system; interactive non-login; functions and aliases)
/etc/profile (system; interactive login; environment variables)
~/.bashrc (user; interactive non-login; functions and aliases)
~/.bash_profile (user; interactive login; environment variables)
Debian
Jedyny, jeden alias znalazłem w ~/.bashrc
pliki użytkownika są kopiowane z /etc/skel/.bashrc
i należy od do bash
dpkg -S /etc/skel/.bashrc
bash: /etc/skel/.bashrc
PCLinuxOS
Zawiera wiecej aliasów i są one w /etc/profile.d/60alias.sh ( locate alias )
i również należy on do pakietu bash ( rpm -qf /sciezka/plik )
Czyli to prawda, że nie ma jednego ustalonego miejsca, ale jest to do odnalezienia.
A co do bezpieczeństwa ...
Może lepiej by było gdyby
/home/uzytkownik/
├── pliki_uzytkownika/ ( nie powinny miec prawa wykonywalnosci )
│
└── pliki_tymczasowe/ ( nie powinny mieć prawa modyfikacji bez podania hasła, oprócz programu przez który zostały stworzone, i bez prawa wykonywalnosci )
Przy pisaniu programów, użytkownik mógłby sobie stworzyć specjalny folder z odpowiednimi uprawnieniami
lub podawałby za kazdym razem haslo użytkownika żeby uruchomić pisany program.
Chociaz tak naprawdę wszystkie pliki tymczasowe powinny być w /tmp
a konfiguracyjne w /etc
Przy aktualizacji systemu, system spyta się czy nadpisać plik w /etc/ , lub go automatycznie pozostawi.
Ale czasami można coś niechcący kliknąć,
dlatego w przypadku bardzo ważnych własnych konfiguracji, warto mieć kopię zapasową.
Chciałbym jeszcze wrócić do " /etc/profile.d/ "
Mnie to trochę zaskoczyło, że jest to polecane.
Podejrzewam, że pierwszą dystrybucją z takim podejsciem była Mandriva i jest to na swój sposób wygodne,
ponieważ możemy tworzyć własne, nowe pliki konfiguracujne i bez problemu kopiować i wklejać do nowego systemu bez obawy nadpisania czegoś.
Oczywiście każdy może mieć inne zdanie, czy lepiej kopiować tylko aliasy, czy pliki z aliasami.
)
===================================}
Listę aliasów można sprawdzić, choć to prawda, że nie pokaże ścieżek do plików ( trzeba sobie poszukać jak ktoś gdzieś upakował nie wiadomo gdzie ( find, grep ))
Nie będę polemizować co lepsze alias, czy skrypt, bo to są dywagacje nt. wyższości świąt Wielkiej Nocy nad Bożego Narodzenia,
Zgadzam się. Oby tylko bezpiecznie:
- odpowiednie uprawnienia
- nie kolidujace miejsce
- nie kolidujaca nazwa
- ( i może nie jakaś komenda dająca szczególne uprawnienia )
Współczesne systemy często w PATH mają nawet ustawione ~/bin/ (jeśli nawet nie ma, to łatwo to ustawić). I to jest właściwe miejsce wg mnie na takie skrypty.
Też tak myślałem, instalując programy, dopóki nie stwierdziłem, że da się je nadpisać.
Aczkolwiek w katalogu domowym mamy także ~/.bashrc i inne, więc chyba nie robi to różnicy pod względem bezpieczeństwa, więc nie zamierzam nikomu zabraniać.
Dla uzytkownika i tak wygodniej, a inny użytkownik ( oprócz root ) od ręki nie uruchomi. ( a bynajmniej nie powinien )
Nie - nie rozwalisz systemu, jeśli zmiany wprowadzasz sensownie.
Popatrz sobie na fragment mojego ~/.bashrc (nie nadaje się - przynajmniej w części dla Ciebie po to inny system):
# Moje aliasy:
alias Syu='sudo pacman -Syu'
alias Rcns='sudo pacman -Rcns'
alias update-grub='sudo grub-mkconfig -o /boot/grub/grub.cfg'
alias mirror='sudo reflector --verbose --latest 5 --sort rate --save /etc/pacman.d/mirrorlist'
alias KDEinfo='qdbus org.kde.KWin /KWin supportInformation'
(nie mówię, że to rozwiązanie najlepsze, jedyne - po prostu wskazuję jak może to wyglądać):
Syu, czy Rcns - tak nazywających się binarek nie dostarcza żadna paczka. Spokojnie zatem mogę zrobić taki alias. Jednocześnie dla mnie jest bardzo czytelne (to fragment polecenia: pacman -Syu lub pacman -Rcns). Podwójnie zatem jest ok: raz - rozwiązanie funkcjonuje wyłącznie na moim koncie, dwa - brak obawy, że jakaś paczka to zdubluje. Podobnie np. w przypadku KDEinfo. Nie ma takiej obawy. Dwa następne wymagają odmiennego potraktowania. Jeśli chodzi o "mirror" - cóż - tu w istocie nie mogę wykluczyć, że jakaś paczka mogłaby dostarczyć tak nazywającej się binarki. Sprawdziłem jednak - nie mam w systemie, zatem może być. Przynajmniej do chwili, w której nie zainstaluję czegoś, co dostarczy /usr/bin/mirror. No i słowo odrębne, czyli update-grub (tak, wiem w AUR jest paczka, która instaluje taki skrypt, jednakże nie jest on mi potrzebny, a ze względu na to, że jest w AUR nie obawiam się, że jakaś paczka instalowana z repozytorium zainstaluje mi taką zależność; to, co buduję z AUR jest natomiast przeze mnie wnikliwie przeglądane). W moim systemie zatem nie ma czegoś takiego jak update-grub - mogę bezpiecznie użyć takiego aliasu. Inaczej sprawa wygląda z Mintem, który taką paczkę dostarcza (nie powiem, czy obecnie to update-grub, czy update-grub2) - ustawienie takiego aliasu byłoby zatem bez sensu.
Jeśli zatem zrobisz z głową, to szanse, że coś sknocisz są minimalne. Nawet jeśli uda Ci się sknocić, to całość wprowadzanych zmian masz w jednym pliku (~/.bashrc), do którego masz dość łatwy dostęp nawet gdy coś w nim sknocisz. Jeśli wszystkie aliasy będziesz miał w jednym miejscu tego pliku to łatwo się tu połapiesz i... wszystko masz czytelne. Przy czym aliasy nadają się na właśnie jakieś skróty dłuższych poleceń. Musisz jednak pamiętać, by nie zastąpić polecenia systemowego. Skrypty - wg mnie - do bardziej zaawansowanego użytku i jeśli już wprowadzane do systemu (czyli nie w /home, a umieszczane w katalogach systemowych), to bezwzględnie za pomocą paczki, którą ich menedżer będzie mógł zarejestrować (tak wiem, w przypadku deb to droga przez mękę, choć o ile pamiętam, to był jakiś programik, który ze skryptów robił nie tylko deb, ale nawet i przetwarzał taki skrypt do binarki).
Jeśli w moim przykładzie, jako alias dałbym coś takiego:
alias pacman='sudo pacman -Rcns'
To wywołanie wówczas systemowej komendy
zwróci informację:
błąd: tylko jedna operacja może być użyta na raz
Łatwo zapomnieć o takim "cudownym" aliasie, a przedstawiając na jakimś forum taki "problem" spowodujesz jedynie konsternację innych użytkowników, bowiem mało kto wpadnie na to, że swoim aliasem podmieniłeś polecenie systemowe i to powoduje jego wadliwe działanie.
Podsumowując: jeśli wiesz co robisz - krzywdy sobie nie zrobisz. Ważne by wiedzieć jak i co.
Aktywna powłoka bash , więc --> ~/.bashrc ( ewentualnie dla root /root/.bashrc , a nie żadne /etc ! ponieważ przy aktualizacji system nadpisze plik )
Nie nadpisze, a przynajmniej nie powinien, bo wtedy koszmarem byłoby wprowadzenie modyfikacji globalnie dla wszystkich użytkowników systemu.
W tym konkrentym przypadku dopisanie zmian do /etc/bash.bashrc jest bezpieczne i nie zostanie utracone przy aktualizacji, o co dba system pakietowania:
%config(noreplace) /etc/bashrc ### Fedora
backup=(etc/bash.bash{rc,_logout} etc/skel/.bash{rc,_profile,_logout}) ### Arch Linux
W przypadku systemu Debian i "zstępnych" system pakietowania automatycznie oznacza pliki w lokalizacji /etc/* jako konfiguracyjne i przy aktualizacji porównuje plik lokalny z plikiem dostarczonym w pakiecie, a w razie różnicy pyta co zrobić.
Zdzichu został przestraszony (czasami się przydaje), zbombardowany informacjami i uwrażliwiony ... "Miej świadomość" jak śpiewa Kazik :D