Czy cd. użyć?

Jeden z samouczków, które śledziłem krótko, stwierdził, że cd .nie ma sensu. Podczas próby odtworzenia problemu pokazanego przez OP w rekursji łącza symbolicznego - co powoduje, że „resetuje się”? , Próbowałem również cd ., który wykazał ten sam opisany efekt OP ( $PWDzmienna rosnąca ), z którym można się przeciwdziałać cd -P.

Zastanawiam się, czy jest jakiś przypadek, w którym ktoś chciałby skorzystać cd . ?

Myślę, że to przesadza z problemem. cd .może nie być czymś, co można by ręcznie uruchomić w zwykłym toku, ale na pewno jest to coś, co może pojawić się przy wykonywaniu programowym (pomyśl o każdej sytuacji, w której możesz cdprzejść do katalogu zawierającego plik, którego ścieżkę podaje użytkownik ). Dlatego nie musi mieć określonego zastosowania: dopóki spełnia normalną semantykę cd <some-path>, jest przydatny.

Ścieżka do katalogu mogła ulec zmianie od czasu wykonania ostatniego polecenia, a bez cd .powłoki bash i ksh93 powłoki będą polegać na logicznym katalogu roboczym opisanym w poście, do którego link znajduje się w pytaniu, więc wywołanie, cd .które powoduje problem z powłoką , wywołuje getcwd()syscall aktualna ścieżka jest nadal aktualna.

Kroki do odtworzenia w bash:

1. W kwestii karty terminalu mkdir ./dir_no_1; cd ./dir_no_1
2. W innym wydaniu karty terminalu mv dir_no_1 dir_no_2
3. W pierwszym wydaniu karty terminalu echo $PWDi pwd. Zauważ, że nazwa katalogu została zmieniona zewnętrznie; środowisko powłoki nie zostało zaktualizowane.
4. Kwestia cd .; pwd; echo $PWD. Zauważ, że wartość została zaktualizowana.

Jednak ksh93 nie aktualizuje informacji o środowisku, więc cd .w ksh93 może być w rzeczywistości bezużyteczny. W /bin/dashsystemach Ubuntu i innych systemach opartych na Debianie cd .zwraca dash: 3: cd: can't cd to .błąd, jednak cd -P .działa (w przeciwieństwie do ksh93).

Innym przykładem użycia cd .może być usunięcie katalogu, w którym aktualnie się znajdujesz, a następnie utworzenie go ponownie. Rozważ wypróbowanie następujących opcji -

1. Utwórz katalog temp
2. cd temp a następnie zrób ls
3. Otwórz inny terminal i usuń, a następnie ponownie utwórz ten katalog temp
4. Wracając z pierwszego terminalu, spróbuj zrobić ls. Spowodowałoby to błąd -ls: cannot open directory .: Stale file handle
5. cd . a następnie wykonanie ls działa dobrze

Możesz to wyczyścić $OLDPWDszybko cd ., jeśli powinien istnieć przypadek, w którym nie chcesz, aby wskazywał „interesujące”. Wpłynie to również cd -.

Programowo jest użyteczny jako brak możliwości. Rozważ ścieżkę podaną z zewnętrznego źródła.

read -p "Path to file: " p
dirn=$(dirname "$p")
file=$(basename "$p")
echo "dirn=$dirn, file=$file"
cd "$dirn"
ls -ld "$file"

Dzięki ścieżce takiej jak „fred.txt” katalog stanie się ., prowadząc docd .

Jest to powszechne, jeśli musiałeś pracować ze złym kablem USB. Po odłączeniu urządzenia i ponownym podłączeniu oraz automatycznym podłączeniu do tego samego katalogu, musisz użyć cd .go, aby ponownie uruchomić urządzenie.

Pamiętaj, że „.” to właściwy sposób na określenie nazwy pliku, który jest otwarty jako bieżący katalog roboczy dowolnego procesu (w tym oczywiście procesu powłoki), i „.” jest zawsze prawidłową nazwą pliku we wszystkich katalogach, w tym w bieżącym katalogu roboczym. Nazwa .może nie być prawidłową nazwą pliku dla danej instancji procesu, jeśli powiedzmy, że bieżący katalog roboczy został usunięty (lub „źle”, np. Nieaktualny uchwyt NFS), ale jest to poprawna nazwa pliku, który na pewno istnieje w każdym prawidłowym katalogu.

. Musi więc być poprawnym argumentem dla każdego polecenia, które akceptuje nazwę katalogu, a zatem w standardowej powłoce cd .musi być poprawnym poleceniem.

To, czy cd .jest przydatne, czy nie, zależy od implementacji powłoki. Jak wspomniano, może być użyteczne, jeśli powłoka resetuje swoją wewnętrzną koncepcję pełnej nazwy ścieżki bieżącego katalogu roboczego po wywołaniu bazowego chdirwywołania systemowego, powiedzmy na przykład, czy nazwa katalogu bazowego (lub jego rodzica) została zmieniona.

Przynajmniej niektóre powłoki, które znam ( /bin/shna FreeBSD i NetBSD), zostaną przekonwertowane cd ""na cd ., co można prawdopodobnie opisać funkcję wspierającą programowe użycie w skrypcie powłoki, w którym zmienna może być użyta jako parametr (tj. Konwersja podstawienia pustej zmiennej na „ „nic nie rób”), choć historia zatwierdzeń FreeBSD mówi, że zmiana była spowodowana bezpośrednio dodaniem obsługi POSIX, aby zapobiec awarii chdir(""), której mandaty POSIX muszą zawieść.

Niektóre inne powłoki zastąpią .wszystko, co zachowały jako w pełni kwalifikowaną ścieżkę do ich bieżącego katalogu roboczego, a zatem dla nich może to pozwolić na zachowanie wymienione w odpowiedzi Sahila Agarwal'a .

Użyłem tego polecenia dopiero dzisiaj, kiedy zmieniłem gałąź, nad którą pracowałem w Git, z katalogu, który został najpierw utworzony w tej samej gałęzi. Rebase poszło dobrze, ale później git statuszgłosił błąd. Po tym cd .wszystkim było normalnie.

(Nawiasem mówiąc, pracowałem w MobaXterm na Windowsie. Na wypadek, gdybyś próbował to odtworzyć. Może się to nie zdarzyć na innych systemach).

Użyłem również tego polecenia w katalogach, które są odświeżane przez zautomatyzowany proces, który odsuwa stary katalog i zastępuje go nowym (tak, aby był jak najbliżej atomu). Nie jest to powszechna sytuacja, ale cd .jest dokładnie tym, czego potrzeba.

Po przeczytaniu tej doskonałej odpowiedzi Stephane Chazelas:

• https://unix.stackexchange.com/a/79621/135943

Teraz rozumiem, że moje powyższe przypadki użycia działają tylko dlatego, że używam bash, w którym cd .jest to równoważne z cd "$PWD". Bardzo polecam przeczytanie połączonej odpowiedzi.

Używam cd .do ponownego uruchomienia rzeczy, które zostały przeciążone cdza pomocą bashfunkcji.

Od mojego ~/.bashrc:

# from the "xttitle(1)" man page - put info in window title
update_title()
{
    [[ $TERM = xterm ]] || [[ $TERM = xterm-color ]]  && xttitle "[$$] ${USER}@${HOSTNAME}:$PWD"
}

cd()
{
    [[ -z "$*" ]] && builtin cd $HOME
    [[ -n "$*" ]] && builtin cd "$*"
    update_title
}

EDYCJA: Sugerowało to wcześniej Sahil .

Jest to przydatne, jeśli znajdujesz się w folderze, który został usunięty i ponownie utworzony przez inny proces. Na przykład zakładając dwie sesje terminalowe $1i $2:

$1 mkdir d
$1 cd d
$1 touch f

$2 rm -rf /path/to/d # delete the folder where $1 is in ...
$2 mkdir /path/to/d # ... and recreate it

$1 touch g # cannot create file g because current dir doesn't exist anymore
touch: cannot touch ‘g’: Stale file handle
$1 cd . # go to the newly created dir (same path)
$1 touch g # works fine now

Nie jestem pewien, czy dokładnie gdzie (OS, SHELL, ...?) Podstawową przyczyną tego zachowania jest.

Nie, to nie ma sensu. Ani w skryptach nic nie robi.