Те, як ви зазвичай включаєте сценарій, є "джерелом"

наприклад:

main.sh:

#!/bin/bash

source incl.sh

echo "The main script"

в т.ч.

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"

.Команда (dot) - псевдонім до source, $PWDє Шлях до робочого каталогу, BASH_SOURCEє змінною масиву, членами якої є джерела файлів, ${string%substring}найменша смуга збігає підрядку $ з тильної сторони $ string

Альтернатива:

scriptPath=$(dirname $0)

є:

scriptPath=${0%/*}

.. перевагою є відсутність залежності від dirname, яка не є вбудованою командою (і не завжди доступна в емуляторах)

Якщо він знаходиться в одному каталозі, ви можете використовувати dirname $0:

#!/bin/bash

source $(dirname $0)/incl.sh

echo "The main script"

Я думаю, що найкращий спосіб зробити це - використовувати спосіб Кріса Борана, Але ви повинні обчислити MY_DIR таким чином:

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

Щоб цитувати довідкові сторінки для readlink:

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він працює.

Поєднання відповідей на це питання дає найбільш надійне рішення.

Це працювало для нас у виробничих сценаріях з великою підтримкою залежностей та структури директорій:

#! / бін / баш

# Повний шлях поточного сценарію
ЦЕ = `readlink -f" $ {BASH_SOURCE [0]} "2> / dev / null || ехо $ 0"

# Каталог, де знаходиться поточний сценарій
DIR = `dirname" $ ​​{ЦЕ}} "`

# "Крапка" означає "джерело", тобто "включати":
. "$ 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.

Це дуже корисно при запуску кронштейнів. Ви отримуєте мінімальне середовище під час запуску cron, але якщо ви робите всі сценарії cron спочатку включають скрипт setenv, то ви зможете керувати та синхронізувати середовище, в якому ви хочете виконати cronjobs.

Ми використовували таку техніку на нашій мавпі, яка будувалась для постійної інтеграції в проект близько 2000 кСЛОК.

Відповідь Стіва, безумовно, є правильною технікою, але вона повинна бути відновлена, щоб змінна installpath знаходилась в окремому сценарії середовища, де зроблено всі такі декларації.

Тоді всі сценарії джерела цього сценарію і повинні встановити шлях змінити, вам потрібно змінити його лише в одному місці. Робить речі більшіми, е, перспективними. Боже, я ненавиджу це слово! (-:

BTW Ви дійсно повинні посилатися на змінну, використовуючи $ {installpath}, використовуючи її так, як показано у вашому прикладі:

. ${installpath}/incl.sh

Якщо дужки не залишиться, деякі оболонки спробують розширити змінну "installpath / incl.sh"!

Shell Script Loader - це моє рішення для цього.

Він надає функцію з назвою include (), яку можна викликати багато разів у багатьох сценаріях для посилання на один сценарій, але завантажить сценарій лише один раз. Функція може приймати цілі шляхи або часткові шляхи (сценарій шукається в шляху пошуку). Також передбачена аналогічна функція з назвою load (), яка буде беззастережно завантажувати сценарії.

Він працює для bash , ksh , pd ksh та zsh з оптимізованими сценаріями для кожного з них; та інші оболонки, які загалом сумісні з оригінальним ш, як попел , тире , реліквія 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 ----'

б.ш

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 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):

IMPORTED="$BASH_SOURCE"

Тепер у вас є доступ до функцій всередині utils.shта вrequirements.sh з ньогоscript.sh

TODO: Напишіть посилання для створення єдиного shфайлу

Використання джерела або $ 0 не дасть вам реального шляху вашого сценарію. Ви можете використовувати ідентифікатор процесу скрипту, щоб отримати його реальний шлях

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для включає. Існує " bash-helper lib" для включення libs таким чином:

#!/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"