我有一个奇怪的看似shell的问题，在$ PATH中的命令，壳（ksh，运行在Linux上）似乎懦弱拒绝调用。 没有完全排除命令，我得到：
# mycommand /bin/ksh: mycommand: not found [No such file or directory] 但可以通过以下方式find该文件：
# which mycommand /home/me/mydir/admbin/mycommand
我也明确地看到$ PATH中的目录：
# echo $PATH | tr : '\n' | grep adm /home/me/mydir/admbin
在那个位置的EXE似乎很正常：
# 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
如果我使用完全限定的path明确运行它：
# /home/me/mydir/admbin/mycommand
我看到预期的产出。 有些东西在这里肯定令人困惑，但是我可能会感到茫然。
编辑：发现什么看起来像一个类似的问题： 二进制将不会执行时，path运行。 例如> ./程序将无法工作，但>程序工作正常
我还testing了多个这样的命令在我的$ PATH，但只find一个：
# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done /home/me/mydir/admbin/mycommand
EDIT2：
截至今天上午， 问题已经消失 ，我现在能够执行可执行文件。
这可以被认为是validation注销和login的build议，但我昨天晚上没有成功完成。 这个注销/login应该也已经完成了相当于运行所提出的'hash -r'命令（这个命令也是一个内置的ksh，而不仅仅是一个内置的bash）。
回答一些答案：
这是一个不是脚本的可执行文件（请参阅文件命令输出中的ELF参考）。
我认为这不会有帮助。 这最终迫使命令执行完全合格。 我想我可以在目前的shell中做一个strace，但是因为我不能再重复，所以没有必要去尝试。
$ PATH中没有分号。 由于我不能再复制，所以我不会用完整的$ PATH来解决这个问题。
尝试另一个shell（即bash）会是我也试过的东西，正如所暗示的那样。 随着问题的消失，我现在不知道这是否会有所帮助。
还有人build议我检查目录权限。 这样做，对于这个目录中的每个目录，我都会看到：
# 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
$ HOME目录的所有权被搞乱了（不应该是根组）。 这可能会导致其他问题，但我不明白这是怎么造成的。
您可能需要使用hash -r更新您的$PATH的项目的caching。
此外，在这种情况下，通过将可执行文件作为parameter passing给dynamic链接程序（可能会在某些系统上setuid / setgid时拒绝这样做）来检查程序调用时会发生的情况。
ldd（1）这两种情况的输出也可能是暴露的。 可执行文件中没有“这样的文件或目录”，这实际上意味着无法find在可执行文件中指定的dynamic链接程序（想象一下，可执行文件中的ELFinforms为＃！/ lib / ld-linux.what.so.ever）
这种行为使人们目瞪口呆，目睹了libc5时代的到来，而现在偶尔在混合i386 / amd64的时代，用不同的方式支持两套图书馆在野外愚弄人们。
可执行文件中的相对RPATH与$ PWD？
PS的另一个问题是关于MacOSX，它可能使用dyld而不是libc提供的链接器。 非常不同的动物。
好的，我没有答案。 我确实certificate了一些事情，我想以后可以补充一下：
所以，总的来说，我还是很困惑。 只是为了咧嘴笑，这是一个与shell相关的bug，你可以用不同的shell来试试吗？
我猜你的脚本在＃！之后没有有效的shell。 例如，在一些较旧的SCO系统上，使用＃！/ bin / bash的脚本不起作用，因为bash真的存在于/ usr / bin / bash中。 愚蠢的，但嘿，上海合作组织几乎是死的原因，不是吗？
检查你的shell，并确保它指向一个真正的二进制/脚本。
编辑：它不知道如果它是一个脚本或二进制文件，但假设你的'ls -l'输出是正确的，那么你可能没有一个93kbyte的脚本…所以这可能是一个二进制的意思是我的答案是完全不正确。
你有没有试过注销并返回？ 我知道如果我使用/ usr / bin中的二进制文件，然后从源代码安装/ usr / local / bin版本，系统仍会尝试执行原始文件，直到我注销并返回。
我的猜测：
你有一个名为mycommand的别名。 例如：
alias mycommand=something
你有一个名为mycommand的函数。 例如：
mycommand() { something; }
下一次有这个问题时，请尝试运行command -V mycommand来查看shell认为mycommand是什么types的命令。
没有答案，只是一堆想法：
我有完全相同的问题，并没有find答案，因为原来的海报的问题自行解决。 但是这对我不起作用，我终于设法跟踪了这个问题。 因此，我将以下内容添加为原始post的答案。
我面临的症状如下。 / my / home目录中有一个脚本（myscript.pl）。 现在试图运行它：
> /my/home/myscript.pl myscript.pl: permission denied.
经过validation的文件权限（执行标志已设置）。 已validation$ PATH（虽然不应该有问题）。
所以然后我尝试（validation脚本上设置的可执行标志）：
> cd /my/home/ > ./myscript.pl: permission denied.
嗯…所以也许脚本没有调用正确的脚本语言（本例中是perl）。 脚本的顶部有正确的魔法：
#!/usr/bin/perl
实际上/ usr / bin / perl的存在和工作。 所以下面的调用工作正常。
/usr/bin/perl myscript.pl
标签自动完成不会显示文件（既不在tcsh也不在bash ）。
这真的把我扔了。 然后想起几个月前我的硬盘坏了，我实验室的年轻系统pipe理员重新安装了这个系统。 以为他可能已经搞砸了分区上的权限。 实际上，在/etc/fstab ，exec权限已经丢失了！
/dev/sda1 /my /ext4 rw,user
代替
/dev/sda1 /my /ext4 rw,user,exec
通过更改/etc/fstab和重新安装来解决这个问题：
mount -v -o remount /my
这完全解决了这个问题。 我的猜测是，除了许可问题是间歇性的（例如，如果发生了重启，可能已经解决了一个临时更改），原始发布者的问题可能会发生类似的情况。