En un mot, oui, ce comportement est attendu. C'est loin d'être idéal mais c'est tout à fait explicable et c'est un produit dérivé de la façon dont les fichiers et les répertoires sont représentés au niveau du système de fichiers.
Il permet de comprendre comment les fichiers et les répertoires sont représentés sur le système de fichiers sous-jacent via les inodes. Et comment le déplacement d'un fichier sur le même système de fichiers ne modifie pas réellement les blocs du fichier, il ne fait que déplacer les métadonnées des inodes.
Prenons un peu de recul et assurons-nous de bien comprendre : lorsque vous supprimez un fichier via le Finder, vous ne le supprimez pas réellement (la plupart du temps). Vous le déplacez simplement vers un emplacement de la corbeille qui se trouve sur la même partition logique que le fichier. Le fait que l'emplacement de la corbeille soit sur la même partition est important. Il permet au système d'exploitation d'exploiter les inodes pour rendre la suppression vraiment, vraiment rapide.
Parlons maintenant des inodes. Pour les fichiers ordinaires, les inodes contiennent les métadonnées du fichier ainsi que des pointeurs vers les blocs de données du système de fichiers qui contiennent réellement les données du fichier. Les métadonnées sont des choses comme la date de création, la date du dernier accès, le propriétaire et le groupe, les paramètres de permissions, etc.
Pour les répertoires, l'inode contient toutes ces métadonnées. plus il contient un pointeur vers une liste de tous les inodes qui sont "dans" ce répertoire. Ainsi, si je "déplace" un fichier sur un système de fichiers, je ne fais que prendre une référence à l'inode de ce fichier à partir de la liste de fichiers d'inodes de son répertoire actuel et le déplacer vers la liste de fichiers d'inodes d'un autre répertoire. La liste a changé, mais la référence à l'inode du fichier n'a pas changé.
Ce brassage des métadonnées signifie que l'emplacement physique des blocs de fichiers et l'inode du fichier lui-même ne changent pas réellement sur le disque. Tout programme accédant actuellement au fichier (en supposant que le verrouillage des fichiers n'est pas utilisé) peut continuer à y accéder même si je le déplace, car toutes les références dont il a besoin sont restées les mêmes. L'inode d'un fichier ou d'un répertoire ne change pas tant qu'il est conservé sur le même système de fichiers. Et lorsque les programmes accèdent aux fichiers et aux répertoires, la plupart de ces accès se font via des références d'inode.
Plutôt chouette.
Mais cela peut donner lieu à un comportement déroutant si vous accédez à un répertoire à partir de plusieurs endroits et que vous déplacez ensuite le répertoire. Et c'est ce que vous rencontrez.
Dans votre cas, vous avez une invite de Terminal dans un répertoire. Lorsque vous avez accédé à ce répertoire, votre shell a lu les métadonnées inodes de ce répertoire et a mis à jour certaines structures de données et variables d'environnement. L'une de ces variables d'environnement était la variable PWD.
Ensuite, vous avez supprimé le répertoire, ce qui a placé l'inode de ce répertoire sous l'icône .Trash la liste des fichiers du répertoire. Les métadonnées de ces deux inodes ont été mises à jour de sorte que le répertoire supprimé a maintenant un attribut de métadonnées de répertoire parent qui pointe sur .Trash et le .Trash a obtenu une nouvelle entrée dans sa liste d'enfants : l'inode du dossier supprimé. Mais votre application Terminal ne savait pas que cela s'était produit. Rien ne lui a dit qu'elle devait recharger ses structures de données. C'est pourquoi pwd y $PWD continuent d'afficher le chemin d'accès original au répertoire. Vous devez déclencher une action dans l'interpréteur de commandes qui provoque la relecture des métadonnées d'inode du répertoire de travail et la génération des structures de données et des variables d'environnement. Cela peut être quelque chose d'aussi simple que d'appeler cd . pour effectuer un changement de répertoire sans intervention. Ou vous pouvez sortir et rentrer dans le répertoire avec des chemins absolus.
La raison pour laquelle cat dans le Terminal fonctionne pour vous montrer un fichier dans ce répertoire est que l'inode que cat utilise pour accéder à ce fichier n'a pas changé juste parce que son emplacement sur le disque a changé. Donc cat peut toujours le trouver étant donné que vous utilisez une référence relative au fichier. Si votre fichier se trouvait à l'origine à /foo/bar/moo.txt et vous avez essayé de faire cat /foo/bar/moo.txt après vous avez supprimé le bar via le Finder, vous verrez que le répertoire cat échouerait avec une erreur de type "file-not-found". Mais cat moo.txt continuerait à fonctionner parce que toutes les structures de données du système de fichiers qui cat doit utiliser pour trouver moo.txt dans votre répertoire de travail n'ont techniquement pas assez changé pour que cat à l'invite de votre Terminal pour en perdre la trace.
C'est la longue explication. J'espère que je ne vous ai pas perdu. :)
