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 ( $PWD
variable 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 .
.
cd-command
Sergiy Kolodyazhnyy
la source
la source
cd .
ces déclenchements parce qu'ils sont simples et brefs. Bien que je pense que vous vouliez que la question soit pour un environnement vanille.$PWD
,cd .
modifie également$OLDPWD
le répertoire en cours. Je n'ai (actuellement) aucune idée du pourquoi cela pourrait être utile, mais dans un souci de complétude…cd .
, même si je trouvais les réponses ci-dessous, je le ferais peut- être à l'avenir, mais je l'ai parfois utilisépushd .
lorsque je voulais pouvoirpopd
revenir à ce répertoire ultérieurement. par exemple, lorsque vous exécutez un script de constructionconfigure
,cd output...
etmake
, et lorsque c'est terminé, je souhaite revenir au répertoire d'origine. Plutôt que de conserver ma propre copie du buildscript qui diffère de ce à quoi tout le monde s’attend, je le lance simplementpushd .; ./BuildScriptName.sh; popd
, et cela me donne également la liberté de ne pas le fairepopd
parfois, etpopd
plus tard à la place./bin/cd
ici unix.stackexchange.com/q/50058/85039Réponses:
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édercd
au 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 decd <some-path>
, il est utile.la source
.
devrait être traité comme un chemin valide spécifié par lacd
syntaxe.IFS= read Dir; do cd "$Dir"; do_something; done < <(find . -type d)
. Au cours de son parcours, find produit.
comme chemin, de sorte que la commande secd "$Dir"
développe encd .
. Donc, dans les scripts, c'est parfaitement utile.cd ${path_to_directory}
, mais à un moment donné, le répertoire est le répertoire actuelpath_to_directory = .
. Vous devrezcd .
donc travailler au cas où.if
contrôles etelse
clauses, tout type de casse spéciale).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'appelcd .
quigetcwd()
provoque le shell à appeler le syscall assurera votre Le chemin actuel est toujours valide.Les étapes pour reproduire en bash:
mkdir ./dir_no_1; cd ./dir_no_1
mv dir_no_1 dir_no_2
echo $PWD
etpwd
. Notez que le répertoire a été renommé en externe. l'environnement du shell n'a pas été mis à jour.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/dash
les systèmes Ubuntu et autres systèmes basés sur Debian,cd .
renvoie unedash: 3: cd: can't cd to .
erreur, maiscd -P .
fonctionne (contrairement à ksh93).la source
mv ../dir_no_1 ../dir_no_2
dans le même terminal / bash.pwd
s'agit en fait d'un composant intégré, mais l'appel/bin/pwd
n'a aucun effet sur l'environnement du shell - les utilitaires externes en général n'affectent pas l'environnement du shell. La raison pour laquelle/bin/cd
et/bin/pwd
existent est entre autres pour la conformité à POSIX. Il y a une bonne discussion sur le cd externe dont certains s'appliquent probablement/bin/pwd
aussiUn 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 -temp
cd temp
et ensuite faire unls
temp
ls: cannot open directory .: Stale file handle
cd .
puis faire un l fonctionne bienla source
cd: can't cd to .
Maintenant que je regarde cela, cela est déjà mentionné dans la réponse de Sergiy (déplacer, supprimer / recréer - en gros le même: le répertoire dans lequel vous vous trouvez n’est plus ce qui était dans l’original chemin)cd .
pour pouvoir accéder au nouveau répertoire portant le même nom.cd .
tout le temps quand j'ai un shell dont le répertoire de travail actuel a été monté avec sshfs mais que la session ssh a été fermée et rouverte.PWD
la variable d'environnement), puis déplacez la hiérarchie du système de fichiers de la racine vers un répertoire accessible par l'intermédiaire de ce chemin, que ce soit en fait le même répertoire ou non. Cela correspond exactement au cas d'utilisation de cette réponse.cd .
fonctionne lorsque le répertoire a été dissocié et qu'un nouveau répertoire différent est créé sur le même chemin de système de fichiers. Le répertoire de travail actuel a été dissociées et vraisemblablement dans le cadre de cela, il n'a plus une.
ou l'..
entrée, et même si elle l'a fait, l'.
entrée devrait continuer à pointer vers lui - même. Il semble que le shell ou le noyau exécute la commande cd en fonction du nom du chemin de répertoire plutôt que d'accéder simplement à l'.
entrée. Quelqu'un peut-il confirmer ce comportement?Vous pouvez effacer
$OLDPWD
en un rapidecd .
, s'il devait y avoir un cas où vous ne voulez pas qu'il pointe n'importe où "intéressant". Ça va aussi affectercd -
.la source
Par programme, c'est utile en tant que non-op. Considérons un chemin fourni à partir d'une entrée externe.
Avec un chemin tel que "fred.txt" le répertoire deviendra
.
, conduisant àcd .
la source
dirname
commande est générée.
si nécessaire pour éviter de déchiffrer le code qui devrait permettre de fractionner un chemin.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.la source
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 standardcd .
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'chdir
appel 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/sh
sur FreeBSD et NetBSD) convertiracd ""
encd .
, 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éfaillancechdir("")
, 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 .la source
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 status
lancé une erreur. Aprèscd .
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:
Je comprends maintenant que mes cas d’utilisation ci-dessus ne fonctionnent que parce que j’utilise
bash
, ce quicd .
équivaut àcd "$PWD"
. Je recommande fortement de lire la réponse liée.la source
J'avais l'
cd .
habitude de relancer les choses que j'avais surchargéescd
via unebash
fonction.De mon
~/.bashrc
:la source
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
$1
et$2
:Je ne suis pas sûr que la cause fondamentale de ce comportement soit où (OS, SHELL, ...?).
la source
Non, ça n'a aucun sens. Ni dans le script, il ne fait rien.
la source
$PWD
et il pourrait éventuellement appeler d'autres fonctions du shell si l'utilisateur avait fourni sa proprecd
fonction ou son alias pour surcharger le programme intégrécd
. Cela vérifierait également que le répertoire actuel est toujours valide et que l'utilisation actuelle est autorisée à s'y trouver.cd .
se plaindre.