Différence entre «commande introuvable» et «aucun fichier ou répertoire»?

Par exemple:

$ node
-bash: /usr/local/bin/node: No such file or directory
$ foo
-bash: foo: command not found

Quelle est la différence? Dans les deux cas, nodeet foosont des commandes invalides, mais il semble qu'Unix ne trouve pas le nodebinaire? Lors de la désinstallation d'un programme, par exemple node, y a-t-il un moyen de le nettoyer pour que je puisse obtenir

$ node
-bash: node: command not found

MODIFIER:

Résultats de typecommande:

$ type node
node is hashed (/usr/local/bin/node)
$ type foo
-bash: type: foo: not found

bash command-line executable gwg
la source

Pouvez-vous mettre à jour votre question avec la sortie des deux type nodeet type foo(bien que seul le premier soit vraiment utile).

Eric Renouf

@ EricRenouf, d'accord, je l'ai fait.

Gwg

C'est probablement que 'noeud' est un lien symbolique de / usr / bin / noeud -> / usr / local / bin / noeud et que ce dernier n'est pas disponible d'où l'erreur, ce qui suggérerait que / usr / local / bin / noeud a été supprimé après la création du lien symbolique.

Likewhoa

Réponses:

C'est parce que bashsouvenez - vous de votre emplacement de commande, stockez-le dans une table de hachage .

Une fois que vous avez désinstallé node, la table de hachage n'est pas effacée, bashpense toujours qu'il nodeest en cours /usr/local/bin/node, ignore la PATHrecherche et appelle /usr/local/bin/nodedirectement à l'aide de execve(). Depuis quand noden'existe plus, erreur execve()renvoie ENOENT, signifie qu'aucun fichier ou répertoire de bashce type ne vous a été signalé.

Dans bash, vous pouvez supprimer une entrée de la table de hachage:

hash -d node

ou supprimez la table de hachage entière ( fonctionne dans tout shell POSIX ):

hash -r

cuonglm
la source

Notez qu'il n'est pas nécessaire /usr/local/bin/nodeque ce soit ce qui manque. si ce fichier est un fichier exécutable lié dynamiquement et qu’une des dépendances est manquante, vous recevrez le même message "Aucun fichier ou répertoire de ce type". Cela peut vous rendre fou jusqu'à ce que vous essayiez lddce fichier.

Guntram Blohm soutient Monica le

@GuntramBlohm mais sur certaines distributions Linux, bash est corrigé pour imprimer des messages d'erreur plus compréhensibles, comme progname: error while loading shared libraries: badLib.so.1: cannot open shared object file: No such file or directory(ou cela pourrait ne pas être bash dans ce cas particulier, mais ld-linux.so).

Ruslan

@Ruslan Dans mon expérience, vous obtenez l'erreur "lors du chargement de bibliothèques partagées" s'il s'agit d'une bibliothèque partagée "ordinaire" manquante et l'inexplicable "Aucun fichier ou répertoire" s'il s'agit de l' éditeur de liens dynamique lui - même qui manque. Cela a du sens lorsque vous réalisez que le premier cas est détecté par l'éditeur de liens dynamique, alors que le dernier cas est détecté par le noyau, et qu'il est beaucoup plus facile pour l'éditeur de liens dynamique d'imprimer un message utile ( execveécrire dans stderr en tant qu'effet secondaire en cas d'échec violerait probablement POSIX ou quelque chose comme ça)

lundi

@zwol ah, c'est ce que certaines correctifs (par exemple CentOS) patch bash. Cette version corrigée imprime ensuite des erreurs telles que /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory.

Ruslan

-6

J'ai trouvé sur Ubuntu Linux 16.04 que "Aucun fichier ou répertoire de ce type" signifie que vous devez changer votre répertoire de travail actuel, tandis que "commande non trouvée" signifie que vous devez utiliser apt-get install xxxyyy_zzz pour résoudre le problème.

Franc
la source

Si votre cwd a une influence sur ce qui sera trouvé ou non (à moins que vous ne le préfixiez par ./), votre PATH est configuré de manière peu sûre. Et une commande introuvable ne constitue pas toujours un problème que vous souhaitez résoudre :)

rackandboneman