![ソース(またはドットコマンド)がファイルの実行を要求しない理由[複製]](https://linux33.com/image/148406/%E3%82%BD%E3%83%BC%E3%82%B9%EF%BC%88%E3%81%BE%E3%81%9F%E3%81%AF%E3%83%89%E3%83%83%E3%83%88%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%EF%BC%89%E3%81%8C%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E5%AE%9F%E8%A1%8C%E3%82%92%E8%A6%81%E6%B1%82%E3%81%97%E3%81%AA%E3%81%84%E7%90%86%E7%94%B1%5B%E8%A4%87%E8%A3%BD%5D.png)
ランニングでhelp .
またはhelp source
現在シェルのファイルにあるコマンドを実行します。
現在のシェルのFILENAMEからコマンドを読み取り、実行します。 $ PATHのエントリは、FILENAMEを含むディレクトリを見つけるために使用されます。
私の観点からは、dotコマンド(またはコマンドsource
)は(他のシェルを作成する代わりに)現在のシェルコンテキストでシェルスクリプトを実行しているようです。
質問.
source
:通常のスクリプトを実行するのと同じようにファイルを実行できるように要求しないのはなぜですか?
答え1
my-script.sh
次に始めるシェルスクリプト()があるとしましょう。
#!/bin/sh
スクリプトに実行権限が設定されている場合は、次のようにスクリプトを実行できます。
./my-script.sh
この場合、カーネルにプログラムとして実行するように要求し、カーネルmy-script.sh
(プログラムローダ)が最初に権限を確認します。それから/bin/sh ./my-script.sh
実際にスクリプトを実行するためのものです。
しかし、 shell( /bin/sh
) は実行権限を気にせず、確認もしません。だからこう呼んだら…
/bin/sh ./my-script.sh
...カーネルはmy-script.sh
プログラムとして実行する必要はありません。カーネル(プログラムローダ)は/bin/sh
。したがって、実行権限は決して検証されません。つまり、これらのスクリプトを実行するために実行権限は必要ありません。
あなたの質問に答えてください:
./my-script.sh
呼び出しとは異なるスクリプトで呼び出すことの違いは. ./my-script.sh
まったく同じです。最初はカーネルにプログラムとして実行するように要求し、2番目は現在のシェルにスクリプトからコマンドを読み取るように要求し、シェルはこれを実行するための実行権限を必要としません(または気にしません)。
追加資料:
スクリプトをプログラムとして実行することは、考えると驚くべき動作です。機械語コードで書かれていません。これがなぜ機能するのかを見てみましょう#!
。https://en.wikipedia.org/wiki/Shebang_(Unix)
共有変数にはドット表記を使用してスクリプトを実行する必要があります。他のすべての実行メカニズムは新しいシェル「コンテキスト」を開始します。これは、呼び出されたスクリプトに設定されたすべての変数が呼び出しスクリプトに戻されないことを意味します。 Bashのドキュメントは少し要約されていますが、ここには次のようなものがあります。https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html
答え2
source script.sh
あなたが話したり. script.sh
スクリプトを実行したりしないとき。あなたが実行しているのは、source
何かをするシェルコマンドです。この「モノ」は、script.sh から読み込んで読み取った内容を実行することで構成されます。これが機能するには、スクリプトを読み取ることができる必要があります。強制性は必要ありません。
動作はランニングbash non-executable-script.sh
などに似ています。python non-executable-script.py