Le point d'interrogation (et les éléments de menu contextuel désactivés) indique que Terminal pense que le répertoire de travail se trouve sur un ordinateur distant et que vous ne pouvez donc pas y accéder dans le Finder à l'aide du menu contextuel. Si vous regardez le dernier élément du menu contextuel (Commande + clic sur l'icône «proxy»), vous verrez l'ordinateur / l'hôte sur lequel Terminal pense que le répertoire de travail est. Vous devriez constater que ce n'est pas le nom actuel de l'ordinateur.
Si vous utilisez bash (le shell par défaut sur macOS), par défaut, il envoie une séquence de contrôle au terminal à chaque invite pour indiquer à Terminal le répertoire de travail actuel. Étant donné que les séquences de contrôle peuvent provenir d'ordinateurs locaux ou distants, il envoie une URL de schéma «fichier:» incluant le nom d'hôte, et Terminal vérifie que le nom est mappé sur la machine actuelle. Si ce n'est pas le cas, Terminal désactive les éléments du menu contextuel du chemin, car ils ne correspondent pas aux répertoires locaux.
Vous pouvez voir le code qui envoie la séquence de contrôle dans /etc/bashrc_Apple_Terminal(ou /etc/bashrcsur les anciennes versions de macOS).
[Notez que si vous n'utilisez pas bash, ou si vous l'avez personnalisé pour que le comportement par défaut ne se produise pas, mais votre shell (ou un autre programme que vous exécutez) envoie des séquences de contrôle pour définir la fenêtre ou l'onglet ( icon) title, Terminal l'examinera pour voir s'il contient ce qui ressemble à un chemin d'accès, puis il vérifie si cela correspond à un chemin d'accès local valide. Sinon, il n'affiche pas du tout l'icône du proxy de fenêtre.]
Un scénario où Terminal peut ne pas reconnaître que l'URL «file:» se trouve sur l'hôte actuel est si vous modifiez votre configuration réseau pendant qu'un shell est en cours d'exécution. Un cas courant consiste à mettre un ordinateur portable en veille et à se déplacer vers un autre endroit, puis à le réveiller. Le nom et l'adresse de l'hôte local auront changé, mais la $HOSTNAMEvariable d'environnement du shell a toujours l'ancien nom d'hôte, et c'est ce qu'elle envoie dans la séquence de contrôle. Pour résoudre ce problème, mettez à jour la variable d'environnement avec:
HOSTNAME=$(hostname)
Un autre scénario consiste à quitter le terminal, à modifier les configurations réseau, puis à ouvrir le terminal avec la reprise activée. Le terminal restaurera les fenêtres et les onglets, ainsi que la dernière URL de répertoire de travail que chacun a été envoyée. Si vous rencontrez ce cas, $HOSTNAMEsera à jour, car il démarre un nouveau shell, mais Terminal peut toujours avoir une URL périmée jusqu'à ce que le shell le mette à jour à nouveau. Si l'affichage de l'invite de commande ne résout pas le problème, essayez de changer de répertoire avec cdpour que le shell le mette à jour.
