I've got a bizarre seeming shell issue, with a command in the $PATH that the shell (ksh, running on Linux) appears to cowardly refuse to invoke. Without fully qualifying the command, I get:
# mycommand /bin/ksh: mycommand: not found [No such file or directory]
but the file can be found by which:
# which mycommand /home/me/mydir/admbin/mycommand
I also explicitly see that directory in $PATH:
# echo $PATH | tr : '\n' | grep adm /home/me/mydir/admbin
The exe at that location seems 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
and if I run it explicitly using a fully qualified path:
I see the expected output. Something is definitely confusing the shell here, but I'm at a loss what it could be?
EDIT: finding what looked like a similar question: Binary won't execute when run with a path. Eg >./program won't work but >program works fine
I also tested for more than one such command in my $PATH, but find only one:
# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done /home/me/mydir/admbin/mycommand
As of this morning, the problem has vanished, and I'm now able to execute the executable.
That could be thought of as validating the suggestion to logout and login, but I'd done that last night without success. That logout/login should have also done the equivalent of running the 'hash -r' command that was suggested (which fwiw also appears to be a ksh builtin, and not just a bash builtin).
In response to some of the answers:
This is an executable not a script (see the ELF reference in the file command output).
I don't think that a strace would have helped. That ends up forcing the command to execute fully qualified. I suppose that I could have done a strace attach on the current shell, but since I can no longer repro there's no point of trying that.
there were no semicolons in the $PATH. Since I can no longer repro, I won't clutter up this question with the full $PATH.
trying another shell (i.e. bash) would have been something I'd also have tried, as was suggested. With the problem gone, I now won't know if that would have helped.
It was also suggested to me was checking the directory permissions. Doing so, for each of the directories up to this one I see:
# 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
The $HOME directory ownership is messed up (shouldn't be root group). That could cause other issues, but I don't see how it would have caused this one.