web-dev-qa-db-ja.com

パス内で実行可能、それによって検索可能ですが、完全修飾パスなしでは実行できませんか？

シェル（ksh、Linuxで実行中）が臆病に呼び出しを拒否しているように見える$ 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ビルトインのように見えます）。

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

  • これはスクリプトではなく実行可能ファイルです（fileコマンド出力の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ディレクトリの所有権がめちゃくちゃになっています（ルートグループであってはなりません）。それは他の問題を引き起こす可能性がありますが、それがこれをどのように引き起こしたのかはわかりません。

linuxksh
12
Peeter Joot

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

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

この振る舞いは、libc5時代の終わりを目撃するために存在していた人々をびっくりさせ、現在では、i386/AMD64が混在する時代の人々を、野生の2つのライブラリセットをサポートするさまざまな手段でびっくりさせました。

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

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

1
rackandboneman

おそらく、$PATHを使用して、hash -r内のシェルのアイテムのキャッシュを更新する必要があります。

1
200_success

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

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

ですから、すべての説明で、私はまだ混乱しています。にやにや笑いながら、これはシェル関連のバグですが、別のシェルで試すことができますか？

0
Jeff Ferland

私の推測：

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

    alias mycommand=something

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

    mycommand() { something; }

次回この問題が発生したときは、command -V mycommandを実行して、シェルがmycommandが信じているコマンドの種類を確認してください。

0
Richard Hansen

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

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

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

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

0
UtahJarhead

答えはありません、ただの考えの束：

  1. ファイル名に空白が含まれているかどうかを確認してください。これは、タブ補完を使用してパラメーターとして使用する場合、警告なしで無視されます。
  2. ディレクトリ内の別のスクリプト/プログラムを試してください。
  3. シェルをstraceして、スクリプトを実行し、どこで壊れるかを確認してください。
0
tim

まったく同じ問題があり、元の投稿者の問題が解決したため、答えを見つけることができませんでした。しかし、これは私にとってはうまくいきませんでした。私はようやく問題を追跡することができました。だから私は元の投稿への回答として以下を追加しています。

私が直面した症状は次のとおりです。/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

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

0
user226160