Dlaczego powinieneś uruchomić cd. zanim cokolwiek zrobisz?

W tej kompilacji horrorów sysadmin jeden z autorów pisze z reguły:

Zawsze rób cd .przed zrobieniem czegokolwiek.

Dlaczego chcesz to zrobić?

directory

— qdii
źródło

Odpowiedzi:

Ty nie.

Przynajmniej nie tak. Ważny jest poprzedni wiersz cytowanego dokumentu:

Ustaw monit, aby robić za pwdkażdym razem, gdy CD.

Zawsze rób cd .przed zrobieniem czegokolwiek.

W ten sposób Ty, jako operator, weryfikujesz swój aktualny katalog przed zrobieniem czegoś ważnego, ponieważ jest on drukowany przy każdej zmianie. cd .inaczej nie ma sensu.

Ta „weryfikacja” jest dobrą rzeczą i należy ją dostosować. Bardziej powszechną odmianą tego motywu (IMHO) jest zawsze wydrukowanie działającego katalogu w odpowiedzi na monit.

— rzymski
źródło

Prawdopodobnie lepiej jest myśleć o tym jako „zawsze pisz„ pwd ”, zanim zrobisz coś ważnego, aby upewnić się, że znajdujesz się w katalogu, w którym uważasz, że jesteś”

— Rod MacPherson

Dlaczego po prostu nie pwdzrobić nic przed zrobieniem czegoś?

— Martin Konecny

W rzeczywistości ma zastosowanie. Jeśli przejdziesz do katalogu za pomocą dowiązania symbolicznego, a następnie link zostanie usunięty i ponownie utworzony w innym miejscu, na przykład podczas wdrażania serwera, gdzie wersje są kontrolowane za pomocą dowiązania symbolicznego do „current_release”, to cd .spowoduje to zmianę faktycznego instrumentu bazowego katalog, w którym jesteś.

— Stewart

+1 dla „ zawsze wydrukować dir pracujący w wierszu”. Tak robię.

— Paddy Landau

@Stewart Niestety nie pomoże to, jeśli dowiązanie symboliczne zmieni się po, cd . ale przed zrobieniem czegoś innego. To po prostu zmniejsza prawdopodobieństwo znalezienia się w niewłaściwym katalogu, ale nie rozwiązuje ogólnego problemu. Chyba że przełączysz się na prawdziwy katalog, używając czegoś takiego, cd $(readlink -f .)biorąc pod uwagę, że faktycznie chcesz tam pozostać.

— scai

Jeśli bieżący katalog roboczy powłoki zostanie usunięty, istnieje możliwość utraty danych.

Na przykład,

$ pwd
/home/user/test
$ rmdir /home/user/test
$ pwd
/home/user/test
$ some_command | tee command.log
tee: command.log: No such file or directory
<long output>

Dane wyjściowe some_commandnie zostały zapisane na dysku.

Wpisanie cd .przed uruchomieniem polecenia ujawni problem.

$ pwd
/home/user/test
$ rmdir /home/user/test
$ cd .
$ pwd
.

Jeśli bieżący katalog katalogu roboczego zostanie usunięty i ponownie utworzony, wpisanie cd .„odświeży” odniesienie do tego katalogu.

$ ls
foo bar ljz
$ pwd
/home/user/test
$ rmdir /home/user/test
$ mkdir /home/user/test
$ pwd
/home/user/test
$ ls
$ cd .
$ ls 
foo bar ljz

Myślę, że ważniejsze jest pokazanie bieżącego katalogu.

Na każdym serwerze linuksowym modyfikuję monit /etc/bashrczmieniając „W” na „W”.

 [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h \W]\\$ "

 [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h \w]\\$ "

Efektem tego jest:

[root@xt include]#

przeciw

[root@xt /usr/src/spl-0.6.1/include]#

— ewwhite
źródło

jest PS1specyficzny dla bash?

— qdii

Myślę, że tak ... To wszystko, czego używam.

— ewwhite

Twoje zmiany mogą zostać utracone podczas następnej aktualizacji systemu, tho.

— ott--

@ ott-- Trzymaj to swoje ~/.profilelub ~/.bash_profileaktualizowanie/etc/skel/.profile

— jscott