シェル（Linuxで実行されているksh）が起動をto病に拒否しているように見える$ PATHにコマンドがあるという奇妙なシェルの問題があります。コマンドを完全に修飾せずに、私は得る：

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

ただし、次の方法でファイルを見つけることができます。

#  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

完全修飾パスを使用して明示的に実行した場合：

#  /home/me/mydir/admbin/mycommand

予想される出力が表示されます。ここで何かが間違いなく混乱しているが、私はそれがどうなるか迷っていますか？

編集：同様の質問のように見えたものを見つける：パスで実行するとバイナリは実行されません。たとえば、> ./ programは動作しませんが、> programは正常に動作します

また、$ PATHでこのようなコマンドを複数テストしましたが、1つしか見つかりませんでした。

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

EDIT2：

今朝の時点で、問題はなくなり、実行可能ファイルを実行できるようになりました。

これは、ログアウトとログインの提案を検証するものと考えることもできますが、昨夜は成功しませんでした。そのログアウト/ログインは、提案された「hash -r」コマンドを実行するのと同じことを行っているはずです（このfwiwは、単なるbashビルトインではなく、kshビルトインでもあるように見えます）。

いくつかの答えに応えて：

• これはスクリプトではなく実行可能ファイルです（ファイルコマンド出力のELFリファレンスを参照）。

• 痕跡が助けになるとは思わない。その結果、コマンドは完全修飾された状態で実行されます。現在のシェルでstrace接続を行うことができたと思いますが、もう再現できないため、それを試す意味はありません。

• $ PATHにセミコロンはありません。私はもはや再現できないので、完全な$ PATHでこの質問を混乱させません。

• 提案されたように、別のシェル（つまりbash）を試すことも、私が試したものでした。問題がなくなったので、それが助けになるかどうかはわかりません。

また、ディレクトリのアクセス許可を確認することが提案されました。これを行うと、これまでの各ディレクトリについて、私は見る：

# 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ディレクトリの所有権が台無しになっています（ルートグループであってはなりません）。それは他の問題を引き起こす可能性がありますが、私はそれがこの問題をどのように引き起こしたかわかりません。

あなたは、おそらくあなたは、中項目のシェルのキャッシュを更新する必要があります$PATH使用してhash -r。

また、そのような場合は、実行可能ファイルを引数として動的リンカーに渡すことで、プログラムが呼び出されたときに何が起こるかを確認します（一部のシステムではsetuid / setgidの実行中に拒否する場合があります）。

両方のケースのldd（1）出力も明らかになる可能性があります。実行可能ファイルの「そのようなファイルまたはディレクトリがない」とは、実行可能ファイルで指定された動的リンカーが実際に見つからないことを意味します（実行可能ファイルの＃！/ lib / ld-linux.what.so.everのELFin形式を想像してください）

この動作は、libc5時代の終わりを目撃するためにそこにいた人々をumb然とさせ、今では野生の2つのライブラリセットをサポートするさまざまな手段でi386 / amd64が混在する時代の人々を時々d然とさせました。

実行可能ファイルの相対RPATH対$ PWD？

PSもう1つの質問はMacOSXに関連しています。MacOSXは、おそらくlibcが提供するリンカーではなくdyldを使用します。動物の非常に異なる種類。

さて、答えはありません。私はいくつかのことを証明しましたが、後でこれに追加できると思います。

• テストファイルを作成しました-あなたの許可はそれがsetuidで実行可能であることを示しています。
• nosuidでマウントポイントに設定しようとしました：まだ実行されています
• noexecでマウントポイントに設定しようとしました：別のエラーが発生しました

だから、すべてのアカウントで、私はまだ混乱している。にやにや笑いのために、これはシェル関連のバグですが、別のシェルで試してみることができますか？

＃！の後のスクリプトには有効なシェルがないと思います。たとえば、一部の古いSCOシステムでは、bashは本当に/ usr / bin / bashにあるため、＃！/ bin / bashを含むスクリプトは機能しません。愚かですが、ちょっとSCOはほとんど理由で死んでいますよね？

シェルをチェックし、実際のバイナリ/スクリプトを指していることを確認してください。

編集：スクリプトかバイナリかはわかりませんが、「ls -l」出力が正しいと仮定すると、おそらく93kバイトのスクリプトはないでしょう...これはおそらくバイナリであり、私の答えは完全に間違っています。

ログアウトしてからログインし直しましたか？/ usr / binにあるバイナリを使用し、ソースから/ usr / local / binバージョンをインストールする場合、システムはログアウトして再度ログインするまで元のバージョンを実行しようとします。

私の推測：

• という名前のエイリアスがありましたmycommand。例えば：

  alias mycommand=something
  

• という名前の関数がありましたmycommand。例えば：

  mycommand() { something; }
  

次回この問題が発生した場合は、実行command -V mycommandしてみて、シェルがどのようなコマンドを信じているかを確認してくださいmycommand。

答えはありませんが、考えはたくさんあります。

1. ファイル名に空白が含まれているかどうかを確認してください。tab-completionを使用してパラメーターとして使用する場合、これは黙って無視されます。
2. ディレクトリ内の別のスクリプト/プログラムを試してください。
3. スクリプトを実行しようとしてシェルをトレースし、どこで破損するかを確認してください。

私はまったく同じ問題を抱えていましたが、元のポスターの問題が解決したため、答えを見つけることができませんでした。しかし、これは私にとってはうまくいかず、ついに問題を突き止めることができました。そこで、元の投稿への回答として以下を追加します。

私が直面した症状は次のとおりです。/ my / homeディレクトリにスクリプト（myscript.pl）があります。今それを実行しようとしています：

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

ファイルの許可を確認しました（実行フラグが設定されています）。$ PATHを検証しました（ただし、問題はないはずです）。

だから、私は試してみます（スクリプトに実行可能フラグが設定されていることを確認した後）：

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

うーん...だから、スクリプトは正しいスクリプト言語（この場合はperl）を呼び出していないのかもしれません。スクリプトの上部には正しい魔法があります。

#!/usr/bin/perl

実際、/ usr / bin / perlが存在し、動作します。したがって、次の呼び出しは正しく機能します。

/usr/bin/perl myscript.pl

タブのオートコンプリートはファイルを表示しtcshません（内でも内でもありませんbash）。

これは本当に私を追い払った。その後、数か月前にハードディスクがクラッシュし、ラボの若いシステム管理者がシステムを再インストールしたことを思い出しました。彼はパーティションのパーミッションを台無しにしたかもしれないと思った。そして確かに、/etc/fstabでは、exec権限がありませんでした！

/dev/sda1    /my     /ext4      rw,user

の代わりに

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

これを修正し、変更/etc/fstabして再マウントします。

mount -v -o remount /my

これで問題は完全に解決しました。私の推測では、許可の問題が断続的であったことを除いて、元のポスターの問題でも同様のことが起こった可能性があります（たとえば、一時的な変更があった場合、再起動で解決される可能性があります）。

完全な答えではありませんが、質問者とまったく同じ問題があり、将来のユーザーが同じ厄介な問題を経験するのを助けるかもしれないと思ったので、私の経験を報告したかったです。私はファイルをどのパスで見ることができ、それを自分のパスで見ることができ、フルパスを与えることでそれを実行することさえできましたが、それ以外は実行できませんでした。しかし、私の場合、それはサブシェル内でのみ発生しました（つまり、スクリプトから実行されたとき、この場合、いくつかのネストされたサブシェルがありました）。コマンドラインから問題なく実行できました。

ネストされたスクリプトのコマンドの直前に、echo $（which mycommand）などのコマンドを出力しました

mycommand：/ home / me / bin / mycommand

次に、親スクリプトから実行しようとします：

/ home / me / bin / some_parent_script [72]：mycommand：not found [そのようなファイルまたはディレクトリはありません]

質問者のように、問題の原因を診断できませんでした。私のPATHは正しいように見えましたが、どちらでもあり、ハッシュはmycommandの以前のエントリを明らかにしませんでした。私がログインした翌日、すべてが魔法のように再び機能しました。ここで、マウントが再マウントされるこの問題を見る直前に発生した既知のシステム問題があったことに注意します。おそらくそれが手掛かりでしょうか？

ログファイルの後にこれが起こったことを示すログファイルがなければ、それが可能であったとは思わないでしょう！質問者のおかげで、私はもう夢中になりません！

PS user226160はレポーターとまったく同じ問題を抱えているとは思わないが、それは関連すると思われ、マウント理論に信end性を与える。