Est-ce que cd. avoir usage?

L'un des tutoriels que j'ai suivis a déclaré brièvement qu'il cd .ne sert à rien. Lorsque vous essayez de reproduire le problème indiqué par OP dans la récursion de lien symbolique, qu'est-ce qui le rend «réinitialisé»? , J’ai aussi essayé cd ., qui présentait le même effet décrit par OP ( $PWDvariable de croissance ), avec laquelle on peut contrer cd -P.

Cela me fait me demander s'il existe un cas où l'on voudrait utiliser cd . .

Je pense que c'est trop penser le problème. cd .Ce n'est peut-être pas quelque chose que l'on pourrait exécuter manuellement dans le cours normal des choses, mais c'est certainement quelque chose qui peut arriver lors d'une exécution programmatique (pensez à toute situation où vous pourriez accéder cdau répertoire contenant un fichier, dont le chemin est fourni par l'utilisateur ). Par conséquent, il n’est pas nécessaire qu’il ait une utilisation spécifique: tant qu’il remplit la sémantique habituelle de cd <some-path>, il est utile.

Le chemin du répertoire pourrait avoir changé depuis l'exécution de la dernière commande. Sans cd .les shells bash et ksh93, le répertoire de travail logique décrit dans l'article lié à la question est appelé. L'appel cd .qui getcwd()provoque le shell à appeler le syscall assurera votre Le chemin actuel est toujours valide.

Les étapes pour reproduire en bash:

1. Dans un problème de terminal mkdir ./dir_no_1; cd ./dir_no_1
2. Dans un autre numéro d'onglet terminal mv dir_no_1 dir_no_2
3. Dans le premier numéro d’onglet terminal echo $PWDet pwd. Notez que le répertoire a été renommé en externe. l'environnement du shell n'a pas été mis à jour.
4. Issue cd .; pwd; echo $PWD. Notez que la valeur a été mise à jour.

Cependant, ksh93 ne met pas à jour les informations sur l'environnement. Par conséquent, cd .ksh93 peut en fait être inutile. Sur /bin/dashles systèmes Ubuntu et autres systèmes basés sur Debian, cd .renvoie une dash: 3: cd: can't cd to .erreur, mais cd -P .fonctionne (contrairement à ksh93).

Un autre cas d'utilisation cd .serait lorsque le répertoire dans lequel vous vous trouvez a été supprimé, puis créé à nouveau. Pensez à essayer ce qui suit -

1. Créer un répertoire temp
2. cd temp et ensuite faire un ls
3. Ouvrir un autre terminal et supprimer puis recréer ce répertoire temp
4. De retour du premier terminal, essayez de faire un ls. Cela entraînerait une erreur -ls: cannot open directory .: Stale file handle
5. cd . puis faire un l fonctionne bien

Vous pouvez effacer $OLDPWDen un rapide cd ., s'il devait y avoir un cas où vous ne voulez pas qu'il pointe n'importe où "intéressant". Ça va aussi affecter cd -.

Par programme, c'est utile en tant que non-op. Considérons un chemin fourni à partir d'une entrée externe.

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

Avec un chemin tel que "fred.txt" le répertoire deviendra ., conduisant àcd .

Ceci est courant si vous devez travailler avec un mauvais câble USB. Une fois qu'un périphérique est déconnecté, connecté à nouveau et monté automatiquement dans le même répertoire, vous devez l'utiliser cd .pour le faire fonctionner à nouveau.

Notez que "." est le moyen approprié de spécifier le nom du fichier ouvert en tant que répertoire de travail actuel de tout processus (y compris un processus shell), et "." est toujours un nom valide de fichier dans tous les répertoires, y compris le répertoire de travail en cours. Le nom .peut ne pas être un nom valide pour un fichier pour une instance donnée d'un processus si, par exemple, le répertoire de travail actuel sous-jacent a été supprimé (ou devenu "incorrect", par exemple un descripteur NFS obsolète), mais s'il s'agit d'un nom valide. d'un fichier dont l'existence est garantie dans chaque répertoire valide.

Donc, . doit être un argument valide pour toute commande qui accepte le nom d'un répertoire, et donc dans le shell standard cd .doit être une commande valide.

Que cela cd .soit utile ou non dépend de l'implémentation du shell. Comme indiqué, il peut être utile que le shell réinitialise sa conception interne du nom de chemin complet du répertoire de travail actuel après l'appel de l' chdirappel système sous-jacent , par exemple si le répertoire sous-jacent (ou un de ses parents) a été renommé.

Au moins quelques obus que je connais ( /bin/shsur FreeBSD et NetBSD) convertira cd ""en cd ., qui peut sans doute être décrit une fonctionnalité permettant de soutenir l' utilisation programmatique dans un script shell où une variable peut être utilisée comme paramètre (ie la conversion d' une substitution de variable vide en un " ne faites rien "en conséquence), bien que l'historique des mises à jour de FreeBSD indique que la modification est directement due à l'ajout du support POSIX pour empêcher une défaillance chdir(""), ce que les mandats POSIX doivent échouer.

Certains autres shells remplaceront .par ce qu'ils ont stocké en tant que chemin d'accès complet à leur répertoire de travail actuel. Cela peut donc permettre le comportement mentionné dans la réponse de Sahil Agarwal .

J'utilisais cette commande aujourd'hui même lorsque je rebasais la branche sur laquelle je travaillais dans Git, à partir d'un répertoire qui avait été créé sur cette même branche. Le rebase s'est bien passé, mais a ensuite git statuslancé une erreur. Après cd .tout était normal.

(Je travaillais d'ailleurs dans MobaXterm sous Windows. Juste au cas où vous essayez de reproduire cela. Cela ne se produira peut-être pas sur d'autres systèmes.)

J'ai également utilisé cette commande dans des répertoires actualisés par un processus automatisé qui déplace l'ancien répertoire et le remplace par un nouveau (il est donc aussi proche que possible de l'atomique). Pas une situation commune, mais cd .c'est exactement ce qui est nécessaire.

Après avoir lu cette excellente réponse de Stéphane Chazelas:

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

Je comprends maintenant que mes cas d’utilisation ci-dessus ne fonctionnent que parce que j’utilise bash, ce qui cd .équivaut à cd "$PWD". Je recommande fortement de lire la réponse liée.

J'avais l' cd .habitude de relancer les choses que j'avais surchargées cdvia une bashfonction.

De mon ~/.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: Cela a déjà été suggéré par Sahil auparavant.

Ceci est utile si vous vous trouvez dans un dossier qui a été supprimé et recréé par un autre processus. Par exemple, en supposant que les deux sessions de terminal $1et $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

Je ne suis pas sûr que la cause fondamentale de ce comportement soit où (OS, SHELL, ...?).

Non, ça n'a aucun sens. Ni dans le script, il ne fait rien.