Tut cd. Verwendung haben?

In einem der Tutorials, die ich verfolgt habe, wurde kurz gesagt, dass cd .es keine Verwendung hat. Wenn versucht wird, das von OP in der Rekursion symbolischer Verknüpfungen angezeigte Problem zu replizieren, warum wird es dann zurückgesetzt? Ich habe auch versucht cd ., den gleichen Effekt OP zu zeigen (wachsende $PWDVariable), mit dem entgegengewirkt werden kann cd -P.

Das lässt mich wundern, gibt es einen Fall, in dem man tatsächlich nutzen möchte cd . ?

Ich denke, das überdenkt das Problem. cd .Es kann sein, dass dies nicht etwas ist, das man im normalen Ablauf manuell ausführen würde, aber es ist definitiv etwas, das bei der programmgesteuerten Ausführung auftreten kann (denken Sie an jede Situation, in der Sie möglicherweise cdzu dem Verzeichnis gelangen, das eine Datei enthält, deren Pfad vom Benutzer angegeben wird ). Daher muss es nicht speziell verwendet werden: Solange es die gewohnte Semantik von erfüllt cd <some-path>, ist es nützlich.

Der Pfad des Verzeichnisses könnte sich geändert haben, seit der letzte Befehl ausgeführt wurde, und ohne cd .die Shells bash und ksh93 wird das in dem in der Frage verlinkten Beitrag beschriebene logische Arbeitsverzeichnis verwendet. Wenn Sie also cd .das Shell-Problem aufrufen , getcwd()wird Ihr Syscall sichergestellt Der aktuelle Pfad ist weiterhin gültig.

Schritte zum Reproduzieren in Bash:

1. In einer Terminal-Registerkarte Problem mkdir ./dir_no_1; cd ./dir_no_1
2. In einem anderen Terminal-Tab Problem mv dir_no_1 dir_no_2
3. In der ersten Registerkarte Terminal Ausgabe echo $PWDund pwd. Beachten Sie, dass das Verzeichnis extern umbenannt wurde. Die Umgebung der Shell wurde nicht aktualisiert.
4. Ausgabe cd .; pwd; echo $PWD. Beachten Sie, dass der Wert aktualisiert wurde.

ksh93 aktualisiert jedoch nicht die Umgebungsinformationen, so dass cd .ksh93 in der Tat unbrauchbar sein kann. In /bin/dashauf Ubuntu und andere Debian-basierten Systemen cd .gibt dash: 3: cd: can't cd to .Fehler, jedoch cd -P .funktioniert ( im Gegensatz zu in ksh93).

Ein weiterer Anwendungsfall von cd .wäre, wenn das Verzeichnis, in dem Sie sich gerade befinden, gelöscht und dann erneut erstellt wurde. Versuchen Sie Folgendes:

1. Erstellen Sie ein Verzeichnis temp
2. cd temp und dann mach ein ls
3. Öffnen Sie ein anderes Terminal, löschen Sie das Verzeichnis und erstellen Sie es neu temp
4. Versuchen Sie, vom ersten Terminal aus ein ls zu machen. Dies würde zu einem Fehler führen -ls: cannot open directory .: Stale file handle
5. cd . und dann funktioniert ein ls gut

Sie können $OLDPWDmit einem kurzen klarstellen cd ., ob es einen Fall geben soll, in dem Sie nicht wollen, dass er irgendwo "interessant" ist. Es wird auch beeinflussen cd -.

Programmatisch ist es als No-Op nützlich. Betrachten Sie einen Pfad, der von einer externen Eingabe bereitgestellt wird.

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

Bei einem Pfad wie "fred.txt" wird das Verzeichnis .zucd .

Dies ist häufig der Fall, wenn Sie mit einem fehlerhaften USB-Kabel arbeiten mussten. Nachdem ein Gerät getrennt und wieder verbunden wurde und automatisch in dasselbe Verzeichnis gemountet wurde, müssen Sie verwenden cd ., damit es wieder funktioniert.

Beachten Sie, dass "." ist die richtige Methode, um den Namen der Datei anzugeben, die als aktuelles Arbeitsverzeichnis eines Prozesses (einschließlich natürlich eines Shell-Prozesses) geöffnet ist, und "." ist immer ein gültiger Name einer Datei in allen Verzeichnissen, einschließlich des aktuellen Arbeitsverzeichnisses. Der Name ist .möglicherweise kein gültiger Name für eine Datei für eine bestimmte Instanz eines Prozesses, wenn beispielsweise das zugrunde liegende aktuelle Arbeitsverzeichnis entfernt wurde (oder "fehlerhaft" geworden ist, z. B. ein veralteter NFS-Punkt), es ist jedoch ein gültiger Name einer Datei, die garantiert in jedem gültigen Verzeichnis existiert.

So . muss ein gültiges Argument für jeden Befehl sein, der den Namen eines Verzeichnisses akzeptiert, und damit in der Standard - Shell cd .muss ein gültiger Befehl sein.

Ob dies cd .sinnvoll ist oder nicht, hängt von der Shell-Implementierung ab. Wie bereits erwähnt, kann es nützlich sein, wenn die Shell nach dem Aufrufen des zugrunde liegenden chdirSystemaufrufs ihre interne Idee des vollständigen Pfadnamens des aktuellen Arbeitsverzeichnisses zurücksetzt , z. B. wenn das zugrunde liegende Verzeichnis (oder ein übergeordnetes Verzeichnis davon) umbenannt wurde.

Zumindest einige der mir bekannten Shells ( /bin/shunter FreeBSD und NetBSD) konvertieren cd ""in cd ., was wohl eine Funktion zur Unterstützung der programmgesteuerten Verwendung in einem Shell-Skript sein kann, bei der eine Variable als Parameter verwendet werden kann (dh das Konvertieren einer leeren Variablensubstitution in eine " "nichts tun"), obwohl der FreeBSD-Commit-Verlauf besagt, dass die Änderung direkt auf das Hinzufügen von POSIX-Unterstützung zurückzuführen ist, um einen Fehler zu verhindern chdir(""), bei dem POSIX-Mandate fehlschlagen müssen.

Einige andere Shells ersetzen das, .was sie als vollständig qualifizierten Pfadnamen zu ihrem aktuellen Arbeitsverzeichnis gespeichert haben, und daher kann dies für sie das in Sahil Agarwals Antwort erwähnte Verhalten zulassen .

Ich habe diesen Befehl erst heute verwendet, als ich den Zweig, an dem ich in Git gearbeitet habe, von einem Verzeichnis aus neu basierte, das zuerst auf demselben Zweig erstellt wurde. Der Rebase ging gut, aber danach git statuswarf einen Fehler. Nachdem cd .alles normal war.

(Ich habe übrigens in MobaXterm unter Windows gearbeitet. Nur für den Fall, dass Sie versuchen, dies zu reproduzieren. Auf anderen Systemen ist dies möglicherweise nicht möglich.)

Ich habe diesen Befehl auch in Verzeichnissen verwendet, die durch einen automatisierten Prozess aktualisiert werden, der das alte Verzeichnis beiseite schiebt und durch ein neues ersetzt (so dass es möglichst atomar ist). Keine alltägliche Situation, aber cd .genau das, was benötigt wird.

Nach dem Lesen dieser ausgezeichneten Antwort von Stephane Chazelas:

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

Ich verstehe jetzt, dass meine oben genannten Anwendungsfälle nur funktionieren, weil ich sie verwende bash, in denen sie cd .äquivalent sind zu cd "$PWD". Ich empfehle dringend, die verlinkte Antwort zu lesen.

Ich benutze es, cd .um das Zeug, mit dem ich überladen bin, cdüber eine bashFunktion erneut auszuführen .

Von meinem ~/.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
}

EDIT: Dies wurde von Sahil bereits zuvor vorgeschlagen .

Dies ist nützlich, wenn Sie sich in einem Ordner befinden, der von einem anderen Prozess gelöscht und neu erstellt wurde. Angenommen, die beiden Terminalsitzungen $1und $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

Ich bin nicht sicher, ob genau (OS, SHELL, ...?) Die Ursache für dieses Verhalten ist.

Nein, es hat keinen Sinn. Weder in der Skripterstellung tut es einfach nichts.