bash - источник без загрязнения собственного пространства имен [безопасное получение переменных из других скриптов]
Вы должны удалить из файла паролей , которое слово ...
Это должно быть примерно так:
root:x:0:0:root:/root:/bin/zsh
Где / bin / zsh - это путь к двоичному файлу оболочки Z.
В текущей конфигурации процесс входа в систему пытается выполнить , который zsh , и эта команда завершается ошибкой.
Также отредактируйте файл как root, например, с помощью sudo vim / etc / passwd , потому что это файл, который доступен для записи только root.
Если вы не можете sudo или su , загрузитесь в режиме восстановления (выберите расширенный вариант для Ubuntu в загрузчике GRUB, затем выберите Ubuntu ... (режим восстановления) , затем выберите root / Drop to root shell prompt). После этого перемонтируйте файловую систему / как чтение-запись ( mount -o remount, rw / ), а затем вы можете редактировать содержимое / etc / passwd файл. Проверено на Ubuntu 16.04.
Используйте eval .
Если у вас есть исходный код (в /tmp/other.sh):
a=1
b=2
c=3
и вам нужна только его часть, вы можете использовать eval , чтобы получить только эти элементы (здесь, в / tmp / main .sh):
eval $(source /tmp/other.sh;
echo a="$a";
echo b="$b";)
echo a is $a "(expect 1)"
echo b is $b "(expect 2)"
echo c is $c "(expect nothing)"
И запускать его:
$ bash /tmp/main.sh
a is 1 (expect 1)
b is 2 (expect 2)
c is (expect nothing)
ПРЕДУПРЕЖДЕНИЕ : выполнение eval или источника на ненадежном скрипте очень опасно. Вы выполняете сценарий оболочки, и этот сценарий может выполнять все, что вы можете сделать сами. ПРЕДУПРЕЖДЕНИЕ
Без использования eval вы все равно можете сделать это с помощью замены процесса, если вы используете bash или подобное:
source <(source "/path/to/file" ; printf %s\\n "depends=${depends[*]}" "makedepends=${makedepends[*]}")
Это запускает подоболочку и источник файла, как и в исходном примере, но затем вместо прямой печати значения и использования подстановки команд он печатает значение, отформатированное как присваивание, и отправляет вывод с помощью подстановки процесса.
Это в точности отвечает на следующую часть вашего вопроса:
Есть ли другой способ, который включает запуск только ОДНОЙ подоболочки, источник файла и получение содержимого указанных переменных файла, назначенного указанным переменным в вызывающей оболочке без загрязнения среды вызывающей оболочки?
Но, конечно, опасность получения внешних сценариев все еще существует. Никогда не создавайте ненадежный сценарий.
Если вы сами написали сценарий и абсолютно уверены , что он не имеет побочных эффектов (и не производит никаких результатов), то вы можете использовать описанное выше для своего персонального компьютера . Это не то, что когда-либо должно быть в производственном сценарии.Очень большая дыра в безопасности.
source <(cat "/path/to/file" | grep "depends\|makedepends")
/path/to/fileвообще не является источником (по сравнению с подходом Wildcard ). См. обсуждение ненадежности выше. Кроме того, если это, например, файл .envиз docker-composeили аналогичный, его можно использовать таким образом, чтобы рисовать переменные другими скриптами без выполнения переменных без кавычек, которые могут вызвать ошибки выполнения. Например, правило внешнего интерфейса -traefik, такое как WEB_FRONTEND_RULE=Host:my.host.name;PathPrefix:/my-path-prefix, которое действительно в docker-compose.env, недопустимо для источника bash. И WEB_FRONTEND_RULE='Host:my.host.name;PathPrefix:/my-path-prefix'действительно для источника bash, но недействительно вdocker-compose.env.
Source или env оба обрабатывают весь сценарий, опасность заключается в том, где и у кого есть доступ для его выполнения. Когда вы используете его внутренне, это нормально.
По теме: если вы используете источник сценария, он работает так же, как и в том же сценарии, поэтому ваши переменные будут просто установлены. Итак, если сценарий 1 — это /tmp/script1.sh:
a=1
b=2
c=3
и сценарий 2, например /tmp/script2.sh
source /tmp/script1.sh
echo $a
echo $b
echo $c
он будет печатать при запуске:
1 2 3
Для меня это наиболее распространенный вариант использования, например, при делегировании общих функций между сценариями (например, обнаружение ОС ).
Возможно, это то, что вы имеете в виду под загрязнением, но, возможно, вы можете определить исходный скрипт с их собственными переменными, и это нормально? Это немного зависит от того, чего вы действительно хотите достичь. Ответ на основе eval также «загрязняет» аналогичным образом, но дает вам больше контроля. Если вы хотите повторно использовать данные, может быть, проще позволить сценариям, которые вы вызываете, просто записывать в текстовый файл и использовать его, или действительно использовать perl, grep, sed или любой другой отличный инструмент unixy, чтобы делать то, что вы хотите.