☰

$PATHが正しく指定されたにもかかわらず、Bashがコマンドを見つけることができないのはなぜですか？

tag-icon • tag-icon linux bash shell ssh path
$PATHが正しく指定されたにもかかわらず、Bashがコマンドを見つけることができないのはなぜですか？

ファイルにコマンドパスを指定します。/etc/設定ファイル:

export PATH=$PATH:/usr/app/cpn/bin

私のコマンドは次の場所にあります。

$ which ydisplay 
/usr/app/cpn/bin/ydisplay

したがって、「echo $PATH」を実行すると、出力は次のようになります。

$ echo $PATH
...:/usr/app/cpn/bin

すべてがうまくいきますが、SSHを介してコマンドを実行しようとするとエラーが発生します。

$ ssh 127.0.0.1 ydisplay
$ bash: ydisplay: command not found

しかし、私の道はまだそこにあります。

$ ssh 127.0.0.1 echo $PATH
...:/usr/app/cpn/bin

SSHセッション中にBashがydisplayを見つけることができない理由と、この問題を回避するためにSSHを正しく構成する方法を説明してください。

さらに、現在のユーザーのローカルファイル.bashrcに$ PATHを指定すると、すべてがうまく機能します。しかし、各ユーザーに複数のファイルを指定するのではなく、1つのファイルのみを変更したいと思います。だから私は尋ねる。

答え1

長すぎます。

代わりにssh 127.0.0.1 ydisplayソースを実行してください。代わりにパスを変更してください。~/.bashrc/etc/profile~/.bashrc

詳細

/etc/profile読み取る唯一の時間は、シェルが「ログインシェル」のときです。

~からバッシュリファレンスマニュアル:

bashがログインシェルとして呼び出されると、... /etc/profileファイルからコマンドを読み込んで実行します。

ただし、実行するとssh 127.0.0.1 ydisplayログインbashシェルで起動しません。しかし、別の起動ファイルを読みます。これバッシュリファレンスマニュアル説明する：

...sshdによって...が実行されるとき。 ...コマンドを読み、実行します。~/.bashrc

PATHだからに設定を入れる必要があります~/.bashrc。

ほとんどのシステムでは、~/.bash_profileソース設定を2つのファイルに配置する代わりに~/.bashrc設定を配置できます。~/.bashrc

すべてのユーザーの設定を変更する標準的な方法はありませんが、ほとんどのシステムには1つ/etc/bashrcまたは/etc/bash.bashrc同様の方法があります。

失敗した場合は設定を指定してくださいpam_env。PATH/etc/environment

また見なさい:

答え2

歴史的に、プロファイル（および/etc/profile）~/.profileはログイン時に呼び出され（テキストコンソールで、何ですか？）、さまざまな目的で使用されました。

  • セッションの環境変数やその他のパラメータ（umaskなど）を設定します。
  • セッションの開始時に追加プログラム（例：Eメール通知）を実行します。
  • シェルと異なる場合（たとえば、他のシェルやX Window）、セッションプログラムを実行します。
  • 端末パラメータを設定します（例stty：）。
  • シェルパラメータ（エイリアスなど）を設定します。

後で、これらすべての目的は別々であることが確認されました。プロファイルスクリプトはインタラクティブセッション（ターミナルインタラクション、他のプログラムの起動）でのみ意味のある操作を実行できるため、リモートシェルが呼び出されると（rsh）が導入されると、rshプロデューサはプロファイルスクリプトが実行されないようにリモートシェルをログインシェルとして呼び出さないことにしました。 （一部のバージョンにはrshdリモートシェルをログインシェルとして実行するオプションがあります。）sshはこの動作を複製してrshをすぐに置き換えます。

プロファイルスクリプトを実行するには、明示的に呼び出すだけです。

ssh 127.0.0.1 '. /etc/profile; . ~/.profile; ydisplay'

.シェル内でプロファイルスクリプトをロードするコマンドに注意してください。このコマンドは外部プログラムではなく、そのシェル内で実行されるコマンドです。

すべてのユーザーに対してグローバルに環境変数を設定する場合は、多くのシステムで異なる方法があります。ではなく/etc/profileで定義することです/etc/environment。ファイルは次のように読み込まれます。pam_envモジュール;ほとんどのLinuxディストリビューションはそれを読むように設定されています。

ログインシェルがbashの場合、より多くの可能性があります。通常、環境変数を設定しないでください。.bashrc（対話型シェルを持つ端末を介していない限り、Xセッションで設定されていないためです。テキストコンソールまたはSSHを介して対話的にログインしている場合は設定されません。から）。しかし、bashには私が全く理解していなかった奇妙な機能があります。~/.bashrc2つの無関係な状況で読んでください。

  • ログインシェルではなく対話型シェルから。
  • ログインシェルではなく非対話型シェルでbashがrshdまたはによって呼び出されたと思う場合sshd。

SSH経由でコマンドを実行すると、2番目の状況になります。 read/etc/profileとfromで.profileプロファイルを読むようにスケジュールできます.bashrc。次のコードを次のトピックに含めます~/.bashrc。

case $- in
  *i*) :;; # this is an interactive shell, fine
  *) # This is not an interactive shell! This must be a non-interactive remote shell session.
    . /etc/profile; . ~/.profile
    return;;
esac

答え3

私は前にこの問題を経験しました。理由は簡単です。

2つの実行可能ファイルが同じ名前を共有し、2つの異なるディレクトリにある場合、シェルは$ PATHの最初のディレクトリでファイルを実行します。

源泉：LinuxでPATHにディレクトリを追加する方法

Pointwiseというアプリケーションがあります。実行可能ファイルの場所を確認したところ、次のことがわかりました。

:~> which pointwise
/usr/local/bin/pointwise

空ですが、インストール時にディレクトリが作成されました。確認すると、$PATH次のような結果が表示されます。

/usr/bin/path:/home/mendezj/bin:/usr/local/bin:/usr/bin:/bin:/opt/pbs/bin:/opt/sim_pkgs/working/apps/POINTWISE

/etc/profile実行可能ファイルの実際のパスを変更して追加しました。問題を解決するために実行可能ファイルの場所を変更しました。変数の先頭に取得します$PATH。

それ:

PATH="$PATH:/opt/sim_pkgs/working/apps/POINTWISE"

私はそれを次のように変更しました：

PATH="/opt/sim_pkgs/working/apps/POINTWISE:$PATH"

移動する前に最初の項目を見ると問題が解決します/usr/local/bin。

関連情報