通常スクリプトを含める方法は「ソース」を使用する方法です

例えば：

main.sh：

#!/bin/bash

source incl.sh

echo "The main script"

incl.sh：

echo "The included script"

「./main.sh」を実行すると、次のように出力されます。

The included script
The main script

...さて、別の場所からそのシェルスクリプトを実行しようとすると、パスにない限り、インクルードを見つけることができません。

スクリプトがインクルードスクリプトを確実に検出できるようにするための良い方法は何ですか（特に、たとえば、スクリプトを移植可能にする必要がある場合）。

私は自分のスクリプトをすべて相互に関連させる傾向があります。そうすれば、dirnameを使用できます。

#!/bin/sh

my_dir="$(dirname "$0")"

"$my_dir/other_script.sh"

パーティーに遅れるのはわかっていますが、スクリプトをどのように開始し、ビルトインを排他的に使用しても、これは機能するはずです。

DIR="${BASH_SOURCE%/*}"
if [[ ! -d "$DIR" ]]; then DIR="$PWD"; fi
. "$DIR/incl.sh"
. "$DIR/main.sh"

.（ドット）コマンドはのエイリアスでありsource、$PWDは作業ディレクトリのパスで、BASH_SOURCE配列変数で、そのメンバーはソースファイル名であり、${string%substring}$ substringの最短一致を$ stringの後ろから削除します

の代替：

scriptPath=$(dirname $0)

です：

scriptPath=${0%/*}

..組み込みコマンドではないdirnameに依存しないことの利点（そして常にエミュレーターで利用できるわけではありません）

同じディレクトリにある場合は、次を使用できますdirname $0。

#!/bin/bash

source $(dirname $0)/incl.sh

echo "The main script"

これを行う最良の方法は、Chris Boranの方法を使用することですが、MY_DIRを次のように計算する必要があります。

#!/bin/sh
MY_DIR=$(dirname $(readlink -f $0))
$MY_DIR/other_script.sh

readlinkのmanページを引用するには：

readlink - display value of a symbolic link

...

  -f, --canonicalize
        canonicalize  by following every symlink in every component of the given 
        name recursively; all but the last component must exist

MY_DIRが正しく計算されないユースケースに遭遇したことはありません。のシンボリックリンクを介してスクリプトにアクセスすると、スクリプトが機能します$PATH。

この質問への回答の組み合わせは、最も堅牢なソリューションを提供します。

依存関係とディレクトリ構造を強力にサポートする本番環境レベルのスクリプトで機能しました。

＃！/ bin / bash

＃現在のスクリプトの完全パス
THIS = `readlink -f" $ {BASH_SOURCE [0]} "2> / dev / null || echo $ 0`

＃現在のスクリプトが存在するディレクトリ
DIR = `dirname" $ {THIS} "`

＃「ドット」は「ソース」、つまり「インクルード」を意味します：
。「$ DIR / compile.sh」

このメソッドは次のすべてをサポートします。

• パス内のスペース
• リンク（を介してreadlink）
• ${BASH_SOURCE[0]} より堅牢です $0

SRC=$(cd $(dirname "$0"); pwd)
source "${SRC}/incl.sh"

これは、スクリプトがソースであっても機能します。

source "$( dirname "${BASH_SOURCE[0]}" )/incl.sh"

1.ニーテスト

私はほとんどすべての提案を調査しました、そしてここに私のために働いた最も最近のものがあります：

script_root=$(dirname $(readlink -f $0))

スクリプトが$PATHディレクトリにシンボリックリンクされている場合でも機能します。

ここで実際にそれを見てください：https：//github.com/pendashteh/hcagent/blob/master/bin/hcagent

2.かっこいい

# Copyright https://stackoverflow.com/a/13222994/257479
script_root=$(ls -l /proc/$$/fd | grep "255 ->" | sed -e 's/^.\+-> //')

これは実際にはこのページの別の回答からのものですが、私の回答にも追加しています！

2.最も信頼できる

または、これらが機能しなかったまれなケースで、防弾アプローチは次のとおりです。

# Copyright http://stackoverflow.com/a/7400673/257479
myreadlink() { [ ! -h "$1" ] && echo "$1" || (local link="$(expr "$(command ls -ld -- "$1")" : '.*-> \(.*\)$')"; cd $(dirname $1); myreadlink "$link" | sed "s|^\([^/].*\)\$|$(dirname $1)/\1|"); }
whereis() { echo $1 | sed "s|^\([^/].*/.*\)|$(pwd)/\1|;s|^\([^/]*\)$|$(which -- $1)|;s|^$|$1|"; } 
whereis_realpath() { local SCRIPT_PATH=$(whereis $1); myreadlink ${SCRIPT_PATH} | sed "s|^\([^/].*\)\$|$(dirname ${SCRIPT_PATH})/\1|"; } 

script_root=$(dirname $(whereis_realpath "$0"))

あなたはtaskrunnerソースでそれを実際に見ることができます：https : //github.com/pendashteh/taskrunner/blob/master/bin/taskrunner

これが誰かを助けることを願っています:)

また、うまくいかなかった場合はコメントとして残し、オペレーティングシステムとエミュレータについて言及してください。ありがとう！

他のスクリプトの場所を指定する必要があります。他の方法はありません。スクリプトの上部に構成可能な変数をお勧めします。

#!/bin/bash
installpath=/where/your/scripts/are

. $installpath/incl.sh

echo "The main script"

または、PROG_HOMEなどのプログラムのホームがどこにあるかを示す環境変数をユーザーが維持するように要求することもできます。これは、/ etc / profile.d /にその情報を含むスクリプトを作成することにより、ユーザーに自動的に提供できます。これは、ユーザーがログインするたびにソースされます。

システム全体のさまざまなコンポーネントの場所を提供することを唯一の目的とするsetenvスクリプトを作成することをお勧めします。

次に、他のすべてのスクリプトがこのスクリプトをソースにするため、setenvスクリプトを使用するすべてのスクリプトですべての場所が共通になります。

これは、cronjobsを実行するときに非常に役立ちます。cronを実行すると最小限の環境が得られますが、すべてのcronスクリプトに最初にsetenvスクリプトを含めるようにすると、cronjobsを実行する環境を制御および同期できます。

私たちは、約2,000 kSLOCのプロジェクト全体で継続的に統合するために使用されたビルドモンキーでこのような手法を使用しました。

Steveの返答は間違いなく正しい手法ですが、installpath変数がそのようなすべての宣言が行われる別の環境スクリプトにあるようにリファクタリングする必要があります。

次に、すべてのスクリプトがそのスクリプトをソースとし、installpathを変更する必要があります。変更する必要があるのは、1つの場所だけです。物事をより確実にし、将来を保証します。神、私はその言葉を憎む！（-：

ところで、例に示されている方法で変数を使用する場合、$ {installpath}を使用して変数を実際に参照する必要があります。

. ${installpath}/incl.sh

中括弧が省略されている場合、一部のシェルは変数「installpath / incl.sh」を展開しようとします。

シェルスクリプトローダーは、これに対する私のソリューションです。

これは、単一のスクリプトを参照するために多くのスクリプトで何度も呼び出すことができるinclude（）という名前の関数を提供しますが、スクリプトは1回しかロードしません。関数は、完全なパスまたは部分的なパスを受け入れることができます（スクリプトは検索パスで検索されます）。無条件にスクリプトをロードするload（）という名前の同様の関数も提供されています。

それはのために働くのbash、kshの、PDのkshとzshのとそれらのそれぞれのために最適化されたスクリプト。シェルが提供できる機能に応じて機能を自動的に最適化するユニバーサルスクリプトを通じて、ash、dash、heirloom shなどの元のshと一般的に互換性のある他のシェル。

【ごちそう例】

start.sh

これはオプションのスタータースクリプトです。ここに起動メソッドを配置するのは便利であり、代わりにメインスクリプトに配置できます。スクリプトをコンパイルする場合も、このスクリプトは必要ありません。

#!/bin/sh

# load loader.sh
. loader.sh

# include directories to search path
loader_addpath /usr/lib/sh deps source

# load main script
load main.sh

main.sh

include a.sh
include b.sh

echo '---- main.sh ----'

# remove loader from shellspace since
# we no longer need it
loader_finish

# main procedures go from here

# ...

灰

include main.sh
include a.sh
include b.sh

echo '---- a.sh ----'

b.sh

include main.sh
include a.sh
include b.sh

echo '---- b.sh ----'

出力：

---- b.sh ----
---- a.sh ----
---- main.sh ----

最良のものは、それに基づいたスクリプトをコンパイルして、使用可能なコンパイラで単一のスクリプトを形成することもできます。

これを使用するプロジェクトは次のとおりです：http : //sourceforge.net/p/playshell/code/ci/master/tree/。スクリプトをコンパイルして、またはコンパイルせずに、移植可能に実行できます。単一のスクリプトを生成するためのコンパイルも発生する可能性があり、インストール時に役立ちます。

また、実装スクリプトがどのように機能するかを簡単に理解したいと考えている保守的な党のために、より単純なプロトタイプを作成しました。https：//sourceforge.net/p/loader/code/ci/base/tree/loader-include-prototype .bash。それは小さく、コードがBash 4.0以降で実行することを意図していて、それを使用しない場合は、メインスクリプトにコードを含めることができますeval。

個人的にすべてのライブラリーをlibフォルダーに入れ、import関数を使用してそれらをロードします。

フォルダ構造

script.sh 内容物

# Imports '.sh' files from 'lib' directory
function import()
{
  local file="./lib/$1.sh"
  local error="\e[31mError: \e[0mCannot find \e[1m$1\e[0m library at: \e[2m$file\e[0m"
  if [ -f "$file" ]; then
     source "$file"
    if [ -z $IMPORTED ]; then
      echo -e $error
      exit 1
    fi
  else
    echo -e $error
    exit 1
  fi
}

このインポート関数はスクリプトの先頭にある必要があり、次のようにライブラリを簡単にインポートできます。

import "utils"
import "requirements"

各ライブラリ（utils.sh）の上部に1行追加します。

IMPORTED="$BASH_SOURCE"

今、あなたは内部の機能へのアクセスを持っているutils.shとrequirements.shから、script.sh

TODO：単一のshファイルを構築するためのリンカーを作成する

ソースまたは$ 0を使用しても、スクリプトの実際のパスはわかりません。スクリプトのプロセスIDを使用して実際のパスを取得できます

ls -l       /proc/$$/fd           | 
grep        "255 ->"            |
sed -e      's/^.\+-> //'

私はこのスクリプトを使用していて、いつもうまくいきました:)

すべての起動スクリプトを.bashrc.dディレクトリに配置しました。これは、/ etc / profile.dなどの場所で一般的な手法です。

while read file; do source "${file}"; done <<HERE
$(find ${HOME}/.bashrc.d -type f)
HERE

グロビングを使用したソリューションの問題...

for file in ${HOME}/.bashrc.d/*.sh; do source ${file};done

...「長すぎる」ファイルリストがある可能性がありますか？のようなアプローチ...

find ${HOME}/.bashrc.d -type f | while read file; do source ${file}; done

...実行されますが、必要に応じて環境は変更されません。

もちろん、それぞれ独自のものですが、以下のブロックはかなりしっかりしていると思います。これには、ディレクトリを見つける「最善の」方法と、別のbashスクリプトを呼び出す「最善の」方法が関係していると思います。

scriptdir=`dirname "$BASH_SOURCE"`
source $scriptdir/incl.sh

echo "The main script"

したがって、これが他のスクリプトを含める「最善の」方法かもしれません。これは別の「最良の」答えに基づいています、bashスクリプトに保存場所を通知ます

これは確実に機能するはずです：

source_relative() {
 local dir="${BASH_SOURCE%/*}"
 [[ -z "$dir" ]] && dir="$PWD"
 source "$dir/$1"
}

source_relative incl.sh

incl.shとmain.shが保存されているフォルダーを見つけるだけです。main.shを次のように変更するだけです。

main.sh

#!/bin/bash

SCRIPT_NAME=$(basename $0)
SCRIPT_DIR="$(echo $0| sed "s/$SCRIPT_NAME//g")"
source $SCRIPT_DIR/incl.sh

echo "The main script"

man hierスクリプトに適した場所は次のとおりです/usr/local/lib/

/ usr / local / lib

ローカルにインストールされたプログラムに関連するファイル。

個人的に/usr/local/lib/bash/includesはインクルードを好む。その方法でlibを含めるためのbash-helper lib があります。

#!/bin/bash

. /usr/local/lib/bash/includes/bash-helpers.sh

include api-client || exit 1                   # include shared functions
include mysql-status/query-builder || exit 1   # include script functions

# include script functions with status message
include mysql-status/process-checker; status 'process-checker' $? || exit 1
include mysql-status/nonexists; status 'nonexists' $? || exit 1

次のものも使用できます。

PWD=$(pwd)
source "$PWD/inc.sh"