J'ai un problème de shell qui semble bizarre, avec une commande dans $ PATH que le shell (ksh, fonctionnant sous Linux) semble lâchement refuser d'invoquer. Sans qualifier complètement la commande, j'obtiens:

#  mycommand
/bin/ksh: mycommand: not found [No such file or directory]

mais le fichier peut être trouvé par lequel:

#  which mycommand
/home/me/mydir/admbin/mycommand

Je vois aussi explicitement ce répertoire dans $ PATH:

#  echo $PATH | tr : '\n' | grep adm
/home/me/mydir/admbin

L'exe à cet endroit semble normal:

#  file /home/me/mydir/admbin/mycommand
/home/me/mydir/admbin/mycommand: setuid setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped

# ls -l mycommand  
-r-sr-s--- 1 me mygroup 97892 2012-04-11 18:01 mycommand

et si je l'exécute explicitement en utilisant un chemin d'accès complet:

#  /home/me/mydir/admbin/mycommand

Je vois la sortie attendue. Quelque chose confond vraiment la coquille ici, mais je ne sais pas ce que cela pourrait être?

EDIT: trouver ce qui ressemblait à une question similaire: le binaire ne s'exécutera pas lorsqu'il est exécuté avec un chemin. Par exemple> ./ le programme ne fonctionnera pas mais> le programme fonctionne bien

J'ai également testé plusieurs commandes de ce type dans mon $ PATH, mais je n'en trouve qu'une:

# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done
/home/me/mydir/admbin/mycommand

EDIT2:

Depuis ce matin, le problème a disparu et je suis maintenant en mesure d'exécuter l'exécutable.

Cela pourrait être considéré comme valider la suggestion de se déconnecter et de se connecter, mais je l'avais fait hier soir sans succès. Cette déconnexion / connexion aurait également dû faire l'équivalent de l'exécution de la commande 'hash -r' qui a été suggérée (qui fwiw semble également être un module intégré ksh, et pas seulement un module intégré bash).

En réponse à certaines des réponses:

• Il s'agit d'un exécutable et non d'un script (voir la référence ELF dans la sortie de la commande file).

• Je ne pense pas qu'une strace aurait aidé. Cela finit par forcer la commande à s'exécuter complètement. Je suppose que j'aurais pu faire une attache strace sur le shell actuel, mais comme je ne peux plus faire de repro, il n'y a pas lieu d'essayer.

• il n'y avait pas de point-virgule dans le $ PATH. Comme je ne peux plus reproduire, je ne vais pas encombrer cette question avec le $ PATH complet.

• essayer un autre shell (c'est-à-dire bash) aurait été quelque chose que j'aurais aussi essayé, comme cela a été suggéré. Le problème étant résolu, je ne saurai maintenant si cela aurait aidé.

Il m'a également été suggéré de vérifier les autorisations du répertoire. Ce faisant, pour chacun des répertoires jusqu'à celui-ci, je vois:

# ls -ld $HOME $HOME/mydir $HOME/mydir/admbin
drwxr-xr-x 10 me root    4096 2012-04-12 12:20 /home/me
drwxrwsr-t 22 me mygroup 4096 2012-04-12 12:04 /home/me/mydir
drwxr-sr-x  2 me mygroup 4096 2012-04-12 12:04 /home/me/mydir/admbin

La propriété du répertoire $ HOME est foirée (ne devrait pas être le groupe racine). Cela pourrait causer d'autres problèmes, mais je ne vois pas comment cela aurait pu causer celui-ci.

Vous devrez probablement mettre à jour le cache des éléments de votre shell dans votre $PATHutilisation hash -r.

De plus, dans de tels cas, vérifiez ce qui se passe lorsque le programme est appelé en passant son exécutable comme argument à l'éditeur de liens dynamique (peut refuser de le faire pendant que setuid / setgid sur certains systèmes).

La sortie ldd (1) des deux cas peut également être révélatrice. "aucun fichier ou répertoire" sur un fichier exécutable signifie vraiment que l'éditeur de liens dynamique spécifié dans le fichier exécutable est introuvable (imaginez l'exécutable ayant une forme ELFin #! / lib / ld-linux.what.so.ever à l'intérieur)

Ce comportement a eu des gens stupéfaits qui étaient là pour assister à la fin de l'ère libc5, et maintenant parfois des gens stupéfaits à l'ère du mélange i386 / amd64 avec différents moyens de prendre en charge deux ensembles de bibliothèques à l'état sauvage.

RPATH relatif dans l'exécutable vs $ PWD?

PS l'autre question est liée à MacOSX, qui utilise probablement dyld et non l'éditeur de liens fourni par libc. Type d'animal très différent.

D'accord, je n'ai pas de réponse. J'ai prouvé quelques choses et je pense que j'y ajouterai plus tard:

• Créé un fichier de test - vos autorisations montrent qu'il est setuid et exécutable.
• J'ai essayé de le placer sur un point de montage avec nosuid: fonctionne toujours
• J'ai essayé de le placer sur un point de montage avec noexec: donne une erreur différente

Donc, selon tous les comptes, je suis toujours aussi confus. Juste pour les sourires et au cas où il s'agit d'un bug lié au shell, pouvez-vous l'essayer avec un shell différent?

Je suppose que votre script n'a pas de shell valide après le # !. Par exemple, sur certains anciens systèmes SCO, les scripts avec #! / Bin / bash ne fonctionnent pas car bash vit VRAIMENT dans / usr / bin / bash. Bête, mais bon SCO est presque mort pour une raison, non?

Vérifiez votre shell et assurez-vous qu'il pointe vers un vrai binaire / script.

Edit: Il ne dit pas si c'est un script ou un binaire, mais en supposant que votre sortie 'ls -l' est correcte, alors vous n'avez probablement pas de script de 93 Ko ... donc c'est probablement un binaire ce qui signifie que ma réponse est totalement incorrect.

Avez-vous essayé de vous déconnecter puis de vous reconnecter? Je sais que si j'utilise un binaire qui se trouve dans / usr / bin puis que j'installe une version / usr / local / bin à partir de la source, le système essaie toujours d'exécuter l'original jusqu'à ce que je me déconnecte et me reconnecte.

Mes suppositions:

• Vous aviez un alias nommé mycommand. Par exemple:

  alias mycommand=something
  

• Vous aviez une fonction nommée mycommand. Par exemple:

  mycommand() { something; }
  

La prochaine fois que vous rencontrez ce problème, essayez d'exécuter command -V mycommandpour voir quel type de commande le shell pense mycommand.

Pas de réponse, juste un tas de réflexions:

1. Vérifiez si le nom de fichier contient des espaces; cela est ignoré en silence lors de l'utilisation de la complétion de tabulation et de l'utilisation comme paramètre.
2. Essayez un autre script / programme dans le répertoire.
3. Essayez de structurer le shell en essayant d'exécuter le script et voyez où il se casse.

J'ai eu exactement le même problème et je n'ai pas trouvé de réponse car le problème de l'affiche originale s'est résolu. Mais cela n'a pas fonctionné pour moi et j'ai finalement réussi à localiser le problème. J'ajoute donc ce qui suit comme réponse au message d'origine.

Les symptômes que j'ai rencontrés étaient les suivants. Il y a un script (myscript.pl) dans le répertoire / my / home. Maintenant, essayons de l'exécuter:

> /my/home/myscript.pl
myscript.pl:  permission denied.

Autorisation vérifiée du fichier (l'indicateur d'exécution est défini). $ PATH vérifié (bien qu'il ne devrait pas y avoir de problème).

Alors j'essaye (après avoir vérifié que le drapeau exécutable est défini sur le script):

> cd /my/home/
> ./myscript.pl:  permission denied.

Hmmm ... Alors peut-être que le script n'appelle pas le bon langage de script (perl, dans ce cas). Le haut du script a la magie correcte:

#!/usr/bin/perl

et en effet / usr / bin / perl existe et fonctionne. L'appel suivant fonctionne donc correctement.

/usr/bin/perl myscript.pl

la saisie automatique des onglets n'affiche pas le fichier (ni dans tcshni dans bash).

Cela m'a vraiment bouleversé. Je me suis alors souvenu qu'il y a quelques mois, mon disque dur était tombé en panne et le jeune administrateur système de mon laboratoire avait réinstallé le système. Je pensais qu'il aurait pu gâcher les autorisations sur les partitions. Et en effet, dans /etc/fstab, l'autorisation d'exécution manquait!

/dev/sda1    /my     /ext4      rw,user

Au lieu de

/dev/sda1    /my     /ext4      rw,user,exec

Corrigé cela en changeant /etc/fstabet en remontant:

mount -v -o remount /my

Cela a résolu le problème complètement. Je suppose qu'une chose similaire aurait pu se produire avec le problème de l'affiche originale, sauf que là, le problème d'autorisation était intermittent (par exemple, il y avait un changement temporaire qui aurait pu être résolu avec un redémarrage, le cas échéant).

Pas une réponse complète, mais je voulais rapporter mon expérience car j'avais exactement le même problème que le questionneur, et je pensais que cela pourrait aider les futurs utilisateurs rencontrant le même problème exaspérant. J'ai pu le fichier, et le voir dans mon chemin, et même l'exécuter en donnant le chemin complet, mais je ne pouvais pas l'exécuter autrement. Cependant, dans mon cas, cela ne s'est produit qu'au sein d'un sous-shell (c'est-à-dire lorsqu'il a été exécuté à partir d'un script, dans ce cas, il y avait quelques sous-shells imbriqués). Je pourrais l'exécuter à partir de la ligne de commande très bien.

Juste avant la commande dans le script imbriqué, j'ai imprimé la commande, par exemple echo $ (dont ma commande)

ma commande: / home / moi / bin / ma commande

Ensuite, j'essayerais de l'exécuter à partir du script parent:

/ home / me / bin / some_parent_script [72]: ma commande: introuvable [Aucun fichier ou répertoire de ce type]

Tout comme le questionneur, je n'ai pas pu diagnostiquer la source du problème. Mon CHEMIN avait l'air correct, c'était possible, et le hachage n'a révélé aucune entrée antérieure de ma commande. Le lendemain, lorsque je me suis connecté, tout a de nouveau fonctionné comme par magie. Maintenant, je vais noter ici qu'il y avait un problème système connu qui s'est produit juste avant de voir ce problème où un montage a été remonté. C'est peut-être un indice?

Si je n'avais pas de fichier journal après fichier journal démontrant que cela s'est produit, je ne pense pas que cela ait été possible! Grâce au questionneur, je ne me sens plus fou!

PS Je ne pense pas que user226160 ait eu le même problème EXACT que le reporter, mais cela semble lié et donne du crédit à la théorie du montage.