En pocas palabras, sí, se espera este comportamiento. Es menos que ideal, pero es completamente explicable y es un biproducto de cómo se representan los archivos y directorios en el nivel del sistema de archivos.
Ayuda a comprender cómo se representan los archivos y directorios en el sistema de archivos subyacente a través de inodos. Y cómo mover un archivo en el mismo sistema de archivos no cambia realmente los bloques de archivos, simplemente baraja los metadatos de inodo.
Sin embargo, retrocedemos un poco y nos aseguramos de que lo entendamos: cuando eliminas un archivo a través del Finder, en la mayoría de los casos no lo estás eliminando. Solo lo está moviendo a una ubicación de basura que está en la misma partición lógica que el archivo. Que la ubicación de la papelera en la misma partición es importante. Permite al sistema operativo explotar los inodos para que la eliminación sea realmente rápida.
Ahora hablemos de inodos. Para los archivos normales, los inodos contienen los metadatos del archivo junto con algunos punteros a los bloques de datos en el sistema de archivos que realmente contienen los datos para el archivo. Los metadatos son cosas como la fecha de creación, la última fecha de acceso, el propietario y el grupo, la configuración de permisos, etc.
Para los directorios, el inodo contiene todos los metadatos más , contiene un puntero a una lista de todos los inodos que están "en" ese directorio. Entonces, si "muevo" un archivo en un sistema de archivos, todo lo que estoy haciendo es sacar una referencia al inodo de ese archivo de la lista de archivos de inodos de su directorio actual y moverlo a la lista de archivos de inodos de otro directorio. La lista cambió, pero la referencia de inodo al archivo no.
Esta mezcla aleatoria de metadatos significa que la ubicación física de los bloques de archivos y el inodo del archivo en sí no cambian en el disco. Cualquier programa que acceda actualmente al archivo (suponiendo que no se esté utilizando el bloqueo de archivos) puede continuar accediéndolo incluso mientras lo muevo porque todas las referencias que necesita se han mantenido igual. El inodo para un archivo o directorio no cambia mientras se mantenga en el mismo sistema de archivos. Y cuando los programas acceden a archivos y directorios, la mayor parte de ese acceso se realiza a través de referencias de inodo.
Bastante limpio
Pero puede llevar a algunos comportamientos discordantes si accede a un directorio desde múltiples lugares y luego lo mueve. Y esto es lo que estás experimentando.
En su caso, tiene un indicador de Terminal en un directorio. Cuando se cambió a ese directorio, su shell leyó los metadatos de inodo para ese directorio y actualizó algunas estructuras de datos y variables de entorno. Una de esas variables de entorno fue la variable PWD.
Luego eliminó el directorio que colocó el inodo de ese directorio en la lista de archivos del directorio .Trash . Los metadatos para estos dos inodos se actualizaron, por lo que el directorio eliminado ahora tenía un atributo de metadatos del directorio padre que apunta a .Trash y los metadatos .Trash inode obtuvieron una nueva entrada en su lista de hijos: el inodo de la carpeta eliminada. Pero tu aplicación de Terminal no sabía que esto había sucedido. No hay nada que le diga que debería recargar sus estructuras de datos. Es por eso que pwd y $PWD continúan mostrando la ruta original al directorio. Tiene que desencadenar una acción en el shell que hace que los metadatos de inodo en el directorio de trabajo se vuelvan a leer y que las estructuras de datos y las variables de entorno se vuelvan a generar. Puede ser algo tan simple como llamado cd . para hacer un directorio de cambio sin operación. O puede salir y volver al directorio con rutas absolutas.
La razón por la que cat en la Terminal funciona para mostrarle un archivo en ese directorio es que el inodo que cat usa para acceder a ese archivo no cambió solo porque cambió su ubicación en el disco. Así que cat todavía puede encontrarlo dado que estás usando una referencia relativa al archivo. Si su archivo se ubicó originalmente en /foo/bar/moo.txt e intentó hacer cat /foo/bar/moo.txt después de borró el directorio bar a través del Finder, vería que la llamada cat fallaría con un archivo -error no encontrado. Pero cat moo.txt continuaría trabajando porque todas las estructuras de datos del sistema de archivos que cat necesitan usar para encontrar moo.txt en su directorio de trabajo técnicamente no han cambiado lo suficiente como para que cat en su indicador de Terminal Server no las detecte.
Esa es la explicación larga. Espero no haberte perdido. :)
