Cfrgtkky

I think this is overthinking the problem. cd . may not be something that one would manually run in the usual course of things, but it definitely is something that can come up in programmatic execution (think of any situation where you might cd to the directory containing a file, whose path is supplied by the user). Therefore, it doesn't have to have some specific use: as long as it fulfills the usual semantics of cd <some-path>, it is useful.

The path of the directory could have changed since the last command was executed, and without cd . the bash and ksh93 shells will rely on the logical working directory described in the post linked in the question, so calling cd . which makes the shell issue the getcwd() syscall will ensure your current path is still valid.

Steps to reproduce in bash:

1. In a terminal tab issue mkdir ./dir_no_1; cd ./dir_no_1
   


2. In a different terminal tab issue mv dir_no_1 dir_no_2
   


3. In the first terminal tab issue echo $PWD and pwd. Notice that the directory has been externally renamed; the shell's environment has not been updated.


4. Issue cd .; pwd; echo $PWD. Notice the value has been updated.

ksh93, however, does not update the environment information, so cd . in ksh93 may in fact be useless. In /bin/dash on Ubuntu and other Debian-based systems, cd . returns dash: 3: cd: can't cd to . error, however cd -P . works (unlike in ksh93).

Another use case of cd . would be when the directory you currently are in has been deleted and then made again. Consider trying the following -

1. Create a directory temp
   


2. 
   cd temp and then do an ls
   


3. Open another terminal and delete and then recreate that directory temp
   


4. Back from the first terminal, try doing an ls. This would result in an error - ls: cannot open directory .: Stale file handle
   


5. 
   cd . and then doing an ls works fine

You can clear $OLDPWD with a quick cd ., if there should be a case where you don't want it to point anywhere "interesting". It'll also affect cd -.

Programmatically it's useful as a no-op. Consider a path provided from external input.

read -p "Path to file: " p

dirn=$(dirname "$p")

file=$(basename "$p")

echo "dirn=$dirn, file=$file"

cd "$dirn"

ls -ld "$file"

With a path such as "fred.txt" the directory will become ., leading to cd .

This is common if you had to work with a bad USB cable. After a device get disconnected and connected again, and automounted to the same directory, you have to use cd . to get it work again.

Note that "." is the proper way to specify the name of the file that is open as the current working directory of any process (including a shell process of course), and "." is always a valid name of a file in any and all directories, including the current working directory. The name . may not be a valid name for a file for a given instance of a process if, say, the underlying current working directory has been removed (or gone "bad", e.g. a stale NFS handle), but it is a valid name of a file that is guaranteed to exist in every valid directory.

So . must be a valid argument for any command that accepts the name of a directory, and thus in the standard shell cd . must be a valid command.

Whether cd . is useful or not depends on the shell implementation. As mentioned it can be useful if the shell resets its internal idea of the full pathname of the current working directory after calling the underlying chdir system call, say for example if the underlying directory (or some parent of it) has been renamed.

At least some shells I know (/bin/sh on FreeBSD and NetBSD) will convert cd "" into cd ., which can arguably be described a feature to support programmatic use in a shell script where a variable might be used as a parameter (i.e. converting an empty variable substitution into a "do nothing" result), though the FreeBSD commit history says the change was directly due to adding POSIX support to prevent a failure from chdir(""), which POSIX mandates must fail.

Some other shells will replace the . with whatever they have stored as the fully qualified pathname to their current working directory, and thus for them this may allow for the behaviour mentioned in Sahil Agarwal's answer.

I used this command just today when I rebased the branch I was working on in Git, from within a directory which had first been created on that same branch. The rebase went fine but afterwards, git status threw an error. After cd . everything was normal.

(I was working in MobaXterm on Windows, incidentally. Just in case you're trying to reproduce this. It may not happen on other systems.)

I also have used this command in directories that are refreshed by an automated process that moves aside the old directory and replaces it with a new one (so it is as close to atomic as possible). Not a common situation but cd . is exactly what's needed.

After reading this excellent answer from Stephane Chazelas:

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

I now understand that my use cases above only work because I am using bash, in which cd . is equivalent to cd "$PWD". I highly recommend reading the linked answer.

I use cd . to rerun the stuff I've overloaded cd with via a bash function.

From my ~/.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: This has already been suggested by Sahil previously.

This is useful if you are inside a folder that got deleted and recreated by another process. For example, assuming the two terminal sessions $1 and $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

I am not sure whether where exactly (OS, SHELL, ...?) the root cause of this behavior is.