Обычно вы включаете скрипт с помощью «source»

например:

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"

Я думаю, что лучший способ сделать это - использовать метод Криса Борана, НО вы должны вычислять MY_DIR следующим образом:

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

Чтобы процитировать man-страницы для 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он работает.

Комбинация ответов на этот вопрос обеспечивает наиболее надежное решение.

Он работал для нас в сценариях промышленного уровня с отличной поддержкой зависимостей и структуры каталогов:

#! / Bin / Баш

# Полный путь текущего скрипта
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. Neatest

Я изучил почти каждое предложение, и вот самое подходящее, которое сработало для меня:

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 выполнялся.

Мы использовали такую ​​технику на нашей сборочной обезьяне, которая использовалась для непрерывной интеграции в рамках проекта около 2000 kSLOC.

Ответ Стива, безусловно, является правильной техникой, но его следует реорганизовать так, чтобы ваша переменная installpath находилась в отдельном скрипте среды, в котором сделаны все такие объявления.

Затем все сценарии исходят из этого сценария и должны изменить путь установки, вам нужно изменить его только в одном месте. Делает вещи более, э, будущее. Боже, я ненавижу это слово! (-:

Кстати, вы действительно должны ссылаться на переменную, используя $ {installpath}, используя ее так, как показано в вашем примере:

. ${installpath}/incl.sh

Если фигурные скобки пропущены, некоторые оболочки попытаются расширить переменную "installpath / incl.sh"!

Shell Script Loader является моим решением для этого.

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

Это работает для bash , ksh , pd ksh и zsh с оптимизированными скриптами для каждого из них; и другие оболочки, которые в общем совместимы с исходным sh, такие как ash , dash , heirloom 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

# ...

a.sh

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

IMPORTED="$BASH_SOURCE"

Теперь у вас есть доступ к функциям внутри utils.shи requirements.shизscript.sh

TODO: написать компоновщик для создания одного shфайла

Использование source или $ 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

Проблема с решением с использованием globbing ...

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 / местные / Библиотека

Файлы, связанные с локально установленными программами.

Лично я предпочитаю /usr/local/lib/bash/includesвключать. Существует библиотека bash-helper для включения библиотек таким образом:

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