¿Tiene cd. tener uso?

Uno de los tutoriales que he seguido brevemente declaró que cd .no tiene ningún uso. Al intentar replicar el problema que muestra OP en la recursividad de enlace simbólico, ¿qué lo hace "restablecer"? , También lo intenté cd ., que mostró el mismo efecto que describió OP ( $PWDvariable de crecimiento ), con el que se puede contrarrestar cd -P.

Esto me hace preguntarme, ¿hay algún caso en el que uno realmente quiera usar cd . ?

Creo que esto es pensar demasiado el problema. cd .puede que no sea algo que se ejecute manualmente en el curso habitual de las cosas, pero definitivamente es algo que puede surgir en la ejecución programática (piense en cualquier situación en la que pueda acceder cdal directorio que contiene un archivo, cuya ruta es suministrada por el usuario ) Por lo tanto, no tiene que tener un uso específico: siempre que cumpla con la semántica habitual cd <some-path>, es útil.

La ruta del directorio podría haber cambiado desde que se ejecutó el último comando, y sin cd .los shells bash y ksh93 se basará en el directorio de trabajo lógico descrito en la publicación vinculada en la pregunta, por lo cd .que llamar a que el shell emita el getcwd()syscall garantizará su La ruta actual sigue siendo válida.

Pasos para reproducir en bash:

1. En una cuestión de pestaña terminal mkdir ./dir_no_1; cd ./dir_no_1
2. En una cuestión de pestaña de terminal diferente mv dir_no_1 dir_no_2
3. En el primer tema de la pestaña terminal echo $PWDy pwd. Observe que el directorio ha sido renombrado externamente; El entorno del shell no se ha actualizado.
4. Problema cd .; pwd; echo $PWD. Observe que el valor ha sido actualizado.

Sin embargo, ksh93 no actualiza la información del entorno, por lo que cd .en ksh93 puede ser inútil. En /bin/dashUbuntu y otros sistemas basados ​​en Debian, cd .devuelve el dash: 3: cd: can't cd to .error, sin embargo cd -P .funciona (a diferencia de ksh93).

Otro caso de uso cd .sería cuando el directorio en el que se encuentra actualmente se haya eliminado y luego se haya creado nuevamente. Considera probar lo siguiente:

1. Crea un directorio temp
2. cd temp y luego hacer un ls
3. Abra otra terminal y elimine y luego vuelva a crear ese directorio temp
4. De vuelta desde la primera terminal, intente hacer un ls. Esto provocaría un error:ls: cannot open directory .: Stale file handle
5. cd . y luego hacer un ls funciona bien

Puede borrar $OLDPWDcon un rápido cd ., si debe haber un caso en el que no desea que apunte a ningún lugar "interesante". También afectará cd -.

Programáticamente es útil como un no-op. Considere una ruta proporcionada desde una entrada externa.

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

Con una ruta como "fred.txt", el directorio se convertirá .encd .

Esto es común si tuviera que trabajar con un cable USB defectuoso. Después de que un dispositivo se desconecte y vuelva a conectar, y se monte automáticamente en el mismo directorio, debe usarlo cd .para que vuelva a funcionar.

Tenga en cuenta que "." es la forma correcta de especificar el nombre del archivo que está abierto como el directorio de trabajo actual de cualquier proceso (incluido un proceso de shell, por supuesto) y "." siempre es un nombre válido de un archivo en todos los directorios, incluido el directorio de trabajo actual. El nombre .puede no ser un nombre válido para un archivo para una instancia determinada de un proceso si, por ejemplo, el directorio de trabajo actual subyacente se ha eliminado (o se ha "dañado", por ejemplo, un identificador NFS obsoleto), pero es un nombre válido de un archivo que se garantiza que existe en cada directorio válido.

Por . lo tanto, debe ser un argumento válido para cualquier comando que acepte el nombre de un directorio y, por lo tanto, en el shell estándar cd .debe ser un comando válido.

Si cd .es útil o no depende de la implementación del shell. Como se mencionó, puede ser útil si el shell restablece su idea interna del nombre de ruta completo del directorio de trabajo actual después de llamar a la llamada del chdirsistema subyacente , por ejemplo, si el directorio subyacente (o alguno de sus padres) ha cambiado de nombre.

Al menos algunas conchas que conozco ( /bin/shen FreeBSD y NetBSD) convertirá cd ""en cd ., que posiblemente se puede describir una característica de apoyo para uso programático en una secuencia de comandos shell donde una variable podría ser utilizado como un parámetro (es decir, la conversión de una sustitución de variables vacío en un " no hacer nada "), aunque el historial de confirmaciones de FreeBSD dice que el cambio se debió directamente a la adición de soporte POSIX para evitar una falla chdir(""), que los mandatos POSIX deben fallar.

Algunos otros shells reemplazarán el .archivo con lo que hayan almacenado como el nombre de ruta completo de su directorio de trabajo actual, y por lo tanto para ellos esto puede permitir el comportamiento mencionado en la respuesta de Sahil Agarwal .

Utilicé este comando justo hoy cuando reformulé la rama en la que estaba trabajando en Git, desde un directorio que se había creado por primera vez en esa misma rama. El rebase salió bien pero luego git statusarrojó un error. Después de que cd .todo fue normal.

(Estaba trabajando en MobaXterm en Windows, por cierto. En caso de que esté intentando reproducir esto. Puede que no suceda en otros sistemas).

También he usado este comando en directorios que se actualizan mediante un proceso automatizado que deja de lado el directorio anterior y lo reemplaza por uno nuevo (por lo que es lo más cercano posible a atómico). No es una situación común, pero cd .es exactamente lo que se necesita.

Después de leer esta excelente respuesta de Stephane Chazelas:

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

Ahora entiendo que mis casos de uso anteriores solo funcionan porque estoy usando bash, en lo que cd .es equivalente a cd "$PWD". Recomiendo leer la respuesta vinculada.

Utilizo cd .para volver a ejecutar las cosas que he sobrecargado cda través de una bashfunción.

De mi ~/.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
}

EDITAR: Esto ya ha sido sugerido por Sahil anteriormente.

Esto es útil si está dentro de una carpeta que fue eliminada y recreada por otro proceso. Por ejemplo, suponiendo las dos sesiones terminales $1y $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

No estoy seguro de dónde está exactamente (OS, SHELL, ...?) La causa raíz de este comportamiento.

No, no tiene sentido. Tampoco en las secuencias de comandos, simplemente no hace nada.