CD. tem uso?

Um dos tutoriais que acompanho afirmou brevemente que cd .não tem utilidade. Ao tentar replicar o problema mostrado pelo OP na recursão do link simbólico - o que o faz "redefinir"? , Também tentei cd ., que mostrou o mesmo efeito descrito no OP ( $PWDvariável crescente ), que pode ser combatido cd -P.

Isso me faz pensar: existe algum caso em que alguém realmente queira usar cd . ?

Eu acho que isso está exagerando no problema. cd .pode não ser algo que seria executado manualmente no curso normal, mas definitivamente é algo que pode surgir na execução programática (pense em qualquer situação em que você possa encontrar cdo diretório que contém um arquivo, cujo caminho é fornecido pelo usuário ) Portanto, ele não precisa ter um uso específico: desde que cumpra a semântica usual cd <some-path>, é útil.

O caminho do diretório poderia ter sido alterado desde que o último comando foi executado, e sem cd .os shells bash e ksh93, o diretório de trabalho lógico descrito no post vinculado na pergunta será chamado, portanto, chamar o cd .que faz com que o shell emita o getcwd()syscall garantirá que seu o caminho atual ainda é válido.

Etapas para reproduzir no bash:

1. Em uma edição da guia terminal mkdir ./dir_no_1; cd ./dir_no_1
2. Em uma questão diferente da guia do terminal mv dir_no_1 dir_no_2
3. Na primeira edição da guia do terminal echo $PWDe pwd. Observe que o diretório foi renomeado externamente; o ambiente do shell não foi atualizado.
4. Issue cd .; pwd; echo $PWD. Observe que o valor foi atualizado.

O ksh93, no entanto, não atualiza as informações do ambiente; portanto, cd .no ksh93 pode ser realmente inútil. No /bin/dashUbuntu e em outros sistemas baseados no Debian, cd .retorna dash: 3: cd: can't cd to .erro, no entanto cd -P .funciona (ao contrário do ksh93).

Outro caso de uso cd .seria quando o diretório em que você está atualmente foi excluído e criado novamente. Considere tentar o seguinte -

1. Crie um diretório temp
2. cd temp e então faça um ls
3. Abra outro terminal, exclua e recrie esse diretório temp
4. De volta do primeiro terminal, tente fazer um ls. Isso resultaria em um erro -ls: cannot open directory .: Stale file handle
5. cd . e depois fazer um ls funciona bem

Você pode limpar $OLDPWDrapidamente cd ., se houver um caso em que não queira que aponte para qualquer lugar "interessante". Isso também afetará cd -.

Programaticamente, é útil como não operacional. Considere um caminho fornecido a partir da entrada externa.

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

Com um caminho como "fred.txt", o diretório se tornará ., levando acd .

Isso é comum se você tiver que trabalhar com um cabo USB ruim. Depois que um dispositivo é desconectado e conectado novamente, e montado automaticamente no mesmo diretório, você precisa usá cd .-lo para fazê-lo funcionar novamente.

Observe que "." é a maneira correta de especificar o nome do arquivo que está aberto como o diretório de trabalho atual de qualquer processo (incluindo um processo de shell, é claro) e "." sempre é um nome válido de um arquivo em todo e qualquer diretório, incluindo o diretório de trabalho atual. O nome .pode não ser um nome válido para um arquivo para uma determinada instância de um processo se, por exemplo, o diretório de trabalho atual subjacente tiver sido removido (ou ficar "ruim", por exemplo, um identificador NFS antigo), mas for um nome válido de um arquivo que é garantido que existe em todos os diretórios válidos.

Portanto, . deve ser um argumento válido para qualquer comando que aceite o nome de um diretório e, portanto, no shell padrão cd .deve ser um comando válido.

Se cd .é útil ou não, depende da implementação do shell. Como mencionado, pode ser útil se o shell redefinir sua idéia interna do nome do caminho completo do diretório de trabalho atual após chamar a chdirchamada de sistema subjacente , por exemplo, se o diretório subjacente (ou algum pai dele) foi renomeado.

Pelo menos alguns shells que eu conheço ( /bin/shno FreeBSD e NetBSD) serão convertidos cd ""em cd ., o que pode ser descrito como um recurso para dar suporte ao uso programático em um shell script em que uma variável pode ser usada como parâmetro (por exemplo, converter uma substituição de variável vazia em um " não faça nada "), embora o histórico de consolidação do FreeBSD diga que a mudança ocorreu diretamente devido à adição do suporte ao POSIX para evitar uma falha chdir(""), da qual os mandatos do POSIX devem falhar.

Alguns outros shells substituirão o que .quer que tenham armazenado como o nome completo do caminho para o diretório de trabalho atual e, portanto, para eles, isso poderá permitir o comportamento mencionado na resposta de Sahil Agarwal .

Eu usei esse comando hoje mesmo quando refiz a nova ramificação em que estava trabalhando no Git, a partir de um diretório que foi criado pela primeira vez na mesma ramificação. O rebase correu bem, mas depois git statusgerou um erro. Depois que cd .tudo estava normal.

(Eu estava trabalhando no MobaXterm no Windows, aliás. Caso você esteja tentando reproduzir isso. Isso pode não acontecer em outros sistemas.)

Também usei esse comando em diretórios que são atualizados por um processo automatizado que se afasta do diretório antigo e o substitui por um novo (por isso é o mais próximo possível do atômico). Não é uma situação comum, mas cd .é exatamente o que é necessário.

Depois de ler esta excelente resposta de Stephane Chazelas:

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

Agora entendo que meus casos de uso acima funcionam apenas porque estou usando bash, no qual cd .é equivalente a cd "$PWD". Eu recomendo ler a resposta vinculada.

Eu uso cd .para executar novamente as coisas que eu sobrecarreguei cdatravés de uma bashfunção.

Do meu ~/.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: Isso já foi sugerido por Sahil anteriormente.

Isso é útil se você estiver dentro de uma pasta que foi excluída e recriada por outro processo. Por exemplo, assumindo as duas sessões do terminal $1e $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

Não sei se exatamente onde (SO, SHELL, ...?) Está a causa raiz desse comportamento.

Não, não tem sentido. Nem no script, ele simplesmente não faz nada.