In breve, sì, questo comportamento è previsto. È meno che ideale, ma è completamente spiegabile ed è un biproduct di come file e directory sono rappresentati a livello di file system.
Aiuta a capire come file e directory sono rappresentati sul file system sottostante tramite inode. E come spostare un file sullo stesso file system non modifica effettivamente i blocchi di file, ma mischia i metadati dell'inode in giro.
Però arretrati un po 'e assicuriamoci che capiamo che: quando elimini un file tramite Finder, non lo fai (per la maggior parte) effettivamente cancellandolo. Lo stai spostando solo in un punto del cestino che si trova sulla stessa partizione logica del file. Che la posizione del cestino si trovi sulla stessa partizione è importante. Permette al sistema operativo di sfruttare gli inode per rendere l'eliminazione davvero, molto veloce.
Ora parliamo di inode. Per i file regolari, gli inode contengono i metadati per il file insieme ad alcuni puntatori ai blocchi di dati sul filesystem che contengono effettivamente i dati per il file. I metadati sono cose come la data di creazione, l'ultima data di accesso, il proprietario e il gruppo, le impostazioni delle autorizzazioni, ecc.
Per le directory l'inode contiene tutti i metadati più contiene un puntatore a un elenco di tutti gli inode che sono "in" quella directory. Quindi, se "muovo" un file su un filesystem tutto quello che sto facendo è prendere un riferimento all'inode di quel file dall'elenco dei file inode della sua directory corrente e spostarlo nell'elenco di file inode di un'altra directory. La lista è cambiata, ma il riferimento inode al file no.
Questo metadata shuffle significa che la posizione fisica dei blocchi di file e l'inode del file stesso non cambiano sul disco. Qualsiasi programma che attualmente acceda al file (supponendo che il blocco dei file non sia in uso) può continuare ad accedervi anche mentre lo sto spostando perché tutti i riferimenti necessari sono rimasti invariati. L'inode per un file o una directory non cambia finché viene mantenuto sullo stesso file system. E quando i programmi accedono a file e directory, la maggior parte di questi viene effettuata tramite riferimenti inode.
Molto carino.
Ma può comportare un comportamento fastidioso se si accede a una directory da più posizioni e quindi si sposta la directory. E questo è quello che stai vivendo.
Nel tuo caso hai un prompt di terminale in una directory. Quando sei passato a quella directory, la tua shell ha letto i metadati dell'inode per quella directory e aggiornato alcune strutture dati e variabili d'ambiente. Una di queste variabili di ambiente era la variabile PWD.
Quindi hai cancellato la directory che ha posizionato l'inode di quella directory sotto l'elenco dei file della directory .Trash . I metadati per questi due inode sono stati aggiornati in modo che la directory eliminata ora avesse un attributo di metadati della directory principale che punta a .Trash e i metadati inode di .Trash hanno ottenuto una nuova voce nel suo elenco di figli: l'inode della cartella eliminata. Ma l'app del tuo terminale non sapeva che questo era successo. Non c'è niente che gli abbia detto che dovrebbe ricaricare le sue strutture dati. Ecco perché pwd e $PWD continuano a mostrare il percorso originale della directory. È necessario attivare un'azione nella shell che causa la rilettura dei metadati inode sulla directory di lavoro e la rigenerazione delle strutture dati e delle variabili di ambiente. Può essere qualcosa di semplice come si chiama cd . per fare una directory di modifica non operante. Oppure puoi uscire e tornare alla directory con percorsi assoluti.
La ragione per cui cat nel Terminale funziona per mostrarti un file in quella directory è che l'inode che cat usa per accedere a quel file non è cambiato solo perché la sua posizione sul disco è cambiata. Quindi cat può ancora trovarlo dato che stai usando un riferimento relativo al file. Se il tuo file si trovava originariamente in /foo/bar/moo.txt e hai provato a fare cat /foo/bar/moo.txt dopo hai eliminato la directory bar tramite Finder, vedresti che la chiamata cat non riuscirebbe con un file -non errore trovato. Ma cat moo.txt continuerà a funzionare perché tutte le strutture di dati del file system che cat deve utilizzare per trovare moo.txt nella directory di lavoro tecnicamente non sono state modificate abbastanza per cat al prompt di Terminale per perdere traccia di esse.
Questa è la lunga spiegazione. Spero di non averti perso. :)
