Fa cd. avere uso?

Uno dei tutorial che ho seguito brevemente ha affermato che cd .non serve a niente. Quando si tenta di replicare il problema mostrato dall'OP nella ricorsione del collegamento simbolico, cosa lo rende "ripristinato"? , Ho anche provato cd ., che ha mostrato lo stesso effetto descritto da OP ( $PWDvariabile crescente ), che può essere contrastato cd -P.

Questo mi fa meravigliare, c'è un caso in cui uno vorrebbe davvero usare cd . ?

Penso che questo stia ripensando il problema. cd .potrebbe non essere qualcosa che si potrebbe eseguire manualmente nel normale corso delle cose, ma è sicuramente qualcosa che può emergere nell'esecuzione programmatica (si pensi a qualsiasi situazione in cui si potrebbe cdraggiungere la directory contenente un file, il cui percorso è fornito dall'utente ). Pertanto, non deve avere un uso specifico: purché soddisfi la solita semantica di cd <some-path>, è utile.

Il percorso della directory potrebbe essere cambiato dall'ultimo comando eseguito, e senza cd .le shell bash e ksh93 si affiderà alla directory di lavoro logica descritta nel post collegato nella domanda, quindi chiamando ciò cd .che causa il problema della shell, getcwd()syscall assicurerà che il percorso corrente è ancora valido.

I passaggi per riprodurre in bash:

1. In un problema con la scheda terminale mkdir ./dir_no_1; cd ./dir_no_1
2. In un diverso problema con la scheda terminale mv dir_no_1 dir_no_2
3. Nel primo problema con la scheda del terminale echo $PWDe pwd. Si noti che la directory è stata rinominata esternamente; l'ambiente della shell non è stato aggiornato.
4. Problema cd .; pwd; echo $PWD. Si noti che il valore è stato aggiornato.

ksh93, tuttavia, non aggiorna le informazioni sull'ambiente, quindi cd .in ksh93 potrebbe in effetti essere inutile. In /bin/dashsu Ubuntu e altri sistemi basati su Debian, cd .restituisce dash: 3: cd: can't cd to .errore, tuttavia cd -P .funziona (a differenza di ksh93).

Un altro caso d'uso cd .potrebbe essere quando la directory in cui ci si trova è stata eliminata e quindi creata di nuovo. Valuta di provare quanto segue:

1. Crea una directory temp
2. cd temp e poi fare un ls
3. Apri un altro terminale ed elimina, quindi ricrea quella directory temp
4. Di ritorno dal primo terminale, prova a fare un ls. Ciò comporterebbe un errore -ls: cannot open directory .: Stale file handle
5. cd . e poi fare un lavoro funziona bene

Puoi chiarire $OLDPWDcon un rapido cd ., se ci dovrebbe essere un caso in cui non vuoi che punti ovunque "interessante". Interesserà anche cd -.

A livello di programmazione è utile come no-op. Considera un percorso fornito dall'input esterno.

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

Con un percorso come "fred.txt" la directory diventerà ., portando acd .

Questo è comune se si dovesse lavorare con un cavo USB difettoso. Dopo che un dispositivo viene disconnesso e ricollegato e montato automaticamente nella stessa directory, è necessario utilizzarlo cd .per farlo funzionare di nuovo.

Nota che "." è il modo corretto di specificare il nome del file che è aperto come directory di lavoro corrente di qualsiasi processo (incluso ovviamente un processo di shell) e "." è sempre un nome valido di un file in tutte le directory, inclusa la directory di lavoro corrente. Il nome .potrebbe non essere un nome valido per un file per una determinata istanza di un processo se, per esempio, la directory di lavoro corrente sottostante è stata rimossa (o è andata "male", ad esempio un handle NFS non aggiornato), ma è un nome valido di un file garantito in ogni directory valida.

Quindi . deve essere un argomento valido per qualsiasi comando che accetta il nome di una directory, e quindi nella shell standard cd .deve essere un comando valido.

L' cd .utilità o meno dipende dall'implementazione della shell. Come accennato, può essere utile se la shell reimposta la sua idea interna del percorso completo della directory di lavoro corrente dopo aver chiamato la chdirchiamata di sistema sottostante , ad esempio se la directory sottostante (o qualche suo genitore) è stata rinominata.

Almeno alcune shell che conosco ( /bin/shsu FreeBSD e NetBSD) verranno convertite cd ""in cd ., che può essere probabilmente descritta una funzione per supportare l'uso programmatico in uno script di shell in cui una variabile potrebbe essere usata come parametro (ovvero convertire una sostituzione di variabile vuota in un " "nessuna operazione"), anche se la cronologia del commit di FreeBSD dice che la modifica è stata direttamente dovuta all'aggiunta del supporto POSIX per prevenire un errore chdir(""), da cui i mandati POSIX devono fallire.

Alcune altre shell sostituiranno .con qualsiasi cosa abbiano archiviato come percorso completo nella loro attuale directory di lavoro, e quindi per loro ciò potrebbe consentire il comportamento menzionato nella risposta di Sahil Agarwal .

Ho usato questo comando proprio oggi quando ho riformulato il ramo su cui stavo lavorando in Git, da una directory che era stata creata per la prima volta su quello stesso ramo. Il rebase è andato bene, ma in seguito ha git statuslanciato un errore. Dopo cd .tutto era normale.

(Lavoravo in MobaXterm su Windows, per inciso. Nel caso in cui tu stia provando a riprodurlo. Potrebbe non accadere su altri sistemi.)

Ho anche usato questo comando in directory che vengono aggiornate da un processo automatizzato che sposta la vecchia directory e la sostituisce con una nuova (quindi è il più vicino possibile all'atomica). Non è una situazione comune ma cd .è esattamente ciò che è necessario.

Dopo aver letto questa eccellente risposta di Stephane Chazelas:

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

Ora capisco che i miei casi d'uso sopra funzionano solo perché sto usando bash, in cui cd .è equivalente cd "$PWD". Consiglio vivamente di leggere la risposta collegata.

Uso cd .di rieseguire le cose che ho sovraccaricato cdtramite una bashfunzione.

Dal mio ~/.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: questo è già stato suggerito da Sahil in precedenza.

Ciò è utile se ci si trova in una cartella che è stata eliminata e ricreata da un altro processo. Ad esempio, ipotizzando le due sessioni terminali $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

Non sono sicuro se la causa principale di questo comportamento sia esattamente (OS, SHELL, ...?).

No, non ha senso. Né negli script, non fa proprio nulla.