Dlaczego aliasing w stosunku do standardowych poleceń nie jest zalecany?

Na przykład wspólny alias, który widziałem w ~/.bashrcpliku (lub odpowiedniki) to

alias rm='rm -i'

Widziałem jednak ludzi, którzy tego nie zalecają, ponieważ

1. alias może nie istnieć w innym systemie, a ponieważ stałeś się nieostrożny rm, przypadkowo usuwasz coś ważnego. [1]
2. Korzystając z tego aliasu, w efekcie trenujesz się w pisaniu ylub yespo każdym rmpoleceniu, które pokonuje cały cel.

Czy istnieją inne powody, aby temu przeciwdziałać? Czy niektóre programy po prostu wykonują wywołania rmzamiast \rm, a aliasing nad nim może powodować dla nich problemy?

Używam rmpo prostu jako przykład, ale widziałem inne polecenia, jak cpi mvobjęte aliasów, jak również. Osobiście powoli uczę się, jak używać takiego aliasu zamiast rm -i:

alias trash=`mv -v -t $HOME/.Trash`

Zakładając, że używasz bash, nie powinno to powodować problemów dla skryptów, ponieważ nieinteraktywne powłoki bash nie dostarczają źródła ~/.bashrclub ~/.bash_profile(co jest prawdopodobne albo w miejscu, gdzie są umieszczone twoje aliasy, albo jest to pierwszy krok do pozyskania aliasów w innym skrypcie) . Może to jednak powodować problemy, jeśli pozyskujesz skrypty:

$ alias echo='command echo foo'
$ cat > script << 'EOF'
> #!/bin/bash
> echo bar
> EOF
$ chmod a+x script
$ ./script
bar
$ . ./script
foo bar

Twoje pytanie obejmuje większość ogólnych obaw związanych z aliasingiem w stosunku do istniejących poleceń, z których najważniejszym jest to, że nieznane środowiska, które na pierwszy rzut oka wydają się takie same, mogą potencjalnie dawać zupełnie inne wyniki. Na przykład aliasing rmdo rm -ima dobre intencje, ale jest zły w praktyce z powodów, które podajesz.

„Czy istnieją inne powody, aby temu polecać?”

Oczywiście:

(3) Ponieważ mam nadzieję, że pewnego dnia dodam do fundamentów zbudowanych przez [-----------] i paranoików, którzy karcą innych za aliasing standardowych poleceń, mimo że standardowe aliasingi są, no cóż, standardowe .

Poważnie, są to tylko zastrzeżenia. Jeśli ufasz sobie, że nie popadniesz w żadną z tych katastrof, po prostu strzeż się i idź dalej.

Osobiście alias bardzo mało standardowych poleceń; Używam niewielkich wariacji, ponieważ jestem trochę paranoiczna i analna. Ale jednym z dobrych zastosowań, które znalazłem w tym zakresie, są systemy, w których często loguję się jako root lub inny użytkownik, a są rzeczy, których nie chcę przypadkowo / leniwie uruchamiać jako root:

alias irc="echo \"No you don't!\""

lub

alias irc="su irc_user"

Jako skrajny przykład, pozwólcie mi tylko na alias standardowego polecenia, aby zilustrować, dlaczego aliasing standardowych poleceń może być szkodliwy:

alias ls='rm'

Oczywiście jest to złe, ponieważ któregoś dnia wywołałoby przykrą niespodziankę. Podobnie zastąpienie standardowych poleceń aliasami ostatecznie doprowadzi do niefortunnej niespodzianki, gdy najmniej się jej spodziewasz.

Ale pozwólcie, że przedstawię wspólny scenariusz, który stanie się prawie każdemu administratorowi Uniksa w miarę rozwoju kariery:

Któregoś dnia w przyszłości zaczniesz nową pracę i będziesz pracować nad nowym systemem, który został skonfigurowany przez innych. W sobotę będzie trzecia rano, a ty nie myślisz prosto i masz skłonność do popełniania błędów. Twoje standardowe środowisko nie będzie dostępne. W rzeczywistości jesteś rootem.

Biorąc to pod uwagę, czy zamierzasz pamiętać, że rmnie jest to alias rm -i? Czy za każdym razem, gdy zalogujesz się do skrzynki, będziesz sprawdzać specjalne aliasy? Jeśli zmienisz środowisko roota, czy twoi współpracownicy będą zadowoleni z twojej zmiany?

Mówię o tym szczerze. W swojej karierze pracowałem na tysiącach systemów i jeśli zmodyfikowałbym środowisko na wszystkich tych systemach, trudno byłoby dostrzec wartość.

Aliasing rmz rm -ijest bardzo powszechny i ​​widziałem, że zapobiega wielu problemom, ale spowodował również wiele niespodzianek i godzin dodatkowej pracy, aby odzyskać przypadkowo usunięte pliki.

Teraz staram się unikać aliasingu typowych poleceń systemowych. Zamiast tego używam aliasów i funkcji do robienia rzeczy, których powłoka nie może łatwo zrobić. Teraz zwykle dołączam dodatkowy list do aliasu, na przykład:

# List long, with color or special characters, depending on OS
alias  ll='ls -l'
# Long, with metacharacters, show dotfiles, don't show . and ..
alias lll='ls -lA'
# Long, with metacharacters, show dotfiles, show . and ..
alias lla='ls -la'
# List just the dotfiles
alias  l.='ls -l -Ad .????*'

# Useful greps
#alias hgrep='history |grep ${*} |grep -v $$'
alias greph='history |grep ${*}'
alias grepp='ps -ef |grep ${*}'

### Highlight some text.
# From http://unix.stackexchange.com/questions/366/convince-grep-to-output-all-lines-not-just-those-with-matches/367#367
highlight () { grep --color -E "$1|$" $2 ; }

I może naprawdę powinienem pozbyć się mojego ostatecznego aliasu, ponieważ dostosowanie się do nowych praktyk wymaga czasu:

# For safety!
alias rm='rm -i'

Jest więcej niebezpieczeństw.

Na przykład, jeśli używasz shell-commandw Emacsie, możesz pomyśleć, że dostajesz „swoje” polecenie (lub alias , ale nie musisz wybierać lsaliasu w terminalu, który wiele razy zanim zapomnisz o ustawieniu aliasu, myśląc o to jak każde inne polecenie ...) - w rzeczywistości (powrót do Emacsa), dostajesz (niezaliczone) polecenie. Emacs wykona to bez problemu, więc możesz być nawet ślepy na to, co się właśnie wydarzyło!

Jeśli chodzi o różne komputery i / lub systemy, jeśli uważasz, że konfigurowanie pojedynczych .rcplików dla nich wszystkich jest zbyt uciążliwe , możesz mieć tylko jeden taki plik, ale z ifklauzulami do dostosowania.

Na przykład, zamiast oceniać każdą funkcję podczas pisania, tylko w przypadku problemów z którąkolwiek z nich, dodaj je do „czarnej listy”, na koniec:

if [[ `uname` == "SunOS" ]]; then
  unset -f mic cpkeep mcp mcph cpindex cpconf # not for Solaris
fi

Zmiana nazw standardowych poleceń według aliasów (tj. rm=rm -i) Z pewnością może prowadzić do niespodzianek, gdy alias nie jest dostępny. Wolę nie używać takiego i (przez kilka gorzkich, gorzkich doświadczeń ;-) stałem acustomed do czytania każde polecenie dwa razy, a jeśli jest to rmlub mvczy cokolwiek innego potencjalnie destrukcyjne trzykrotnie. I takie aliasy prowadzą do automatycznego „rm foo” ENTER ”y” Ups !! mimo to (i za każdym razem kosztuje dodatkowe naciśnięcie klawisza).

Ale to tylko ja. Jeśli nie spodziewasz się, że będziesz działać w obcych środowiskach (inne maszyny, inni użytkownicy, ...) i możesz zainstalować swoje ulubione aliasy gdziekolwiek jesteś, szaleją. Znany jest system Unix, który zapewnia użytkownikom więcej niż wystarczającą ilość liny, aby strzelać własnymi stopami.

Inne odpowiedzi są dobre, ale wszystkie tylko patrzą, jak to wpływa na ciebie.

Pozwólcie, że trochę odwrócę odpowiedź Stephana Laswieskiego.

Zakładając, że nie jesteś wszechwiedzący, może być konieczne, aby ktoś inny pracował na Twoim koncie użytkownika lub doradził, jak coś zrobić.

Następnie, gdy coś zrobią lub powiedzą ci, aby to zrobić, może nie działać zgodnie z oczekiwaniami.

W najlepszym razie będziesz musiał tracić czas na wyjaśnianie im, co się stało (jeśli jesteś tam i pamiętasz lub odkryłeś, że przyczyną problemu był alias).

W najgorszym przypadku zobacz zwrot w przykładzie w jednej z pozostałych odpowiedzi: alias ls = 'rm -rf'.