У меня есть сценарий оболочки Korn
#!/bin/ksh
# set the right ENV
case $INPUT in
abc)
export BIN=${ABC_BIN}
;;
def)
export BIN=${DEF_BIN}
;;
*)
export BIN=${BASE_BIN}
;;
esac
# exit 0 <- bad idea for sourcing the file
теперь эти переменные экспортируются только в подоболочке, но я хочу, чтобы они были установлены и в моей родительской оболочке, поэтому, когда я нахожусь в командной строке, эти переменные по-прежнему устанавливаются правильно.
Я знаю о
. .myscript.sh
но есть ли способ сделать это без "поиска"? поскольку мои пользователи часто забывают «источник».
EDIT1: удаление части "exit 0" - это просто я печатал, не задумываясь
EDIT2: чтобы добавить более подробную информацию о том, зачем мне это: мои разработчики пишут код (для простоты) для двух приложений: ABC и DEF. каждое приложение запускается в производственной среде отдельными пользователями usrabc и usrdef, поэтому они настроили свои $ BIN, $ CFG, $ ORA_HOME, что угодно - для своих приложений.
так
и т.п.
теперь в dev box разработчики могут разрабатывать как ABC, так и DEF одновременно под своей собственной учетной записью «justin_case», и я заставляю их исходить из файла (см. выше), чтобы они могли переключать свои настройки ENV var туда и обратно. ($ BIN должен одновременно указывать на $ ABC_BIN, а затем мне нужно переключиться на $ BIN = $ DEF_BIN)
теперь сценарий также должен создавать новые песочницы для параллельной разработки одного и того же приложения и т. д. Это заставляет меня делать это в интерактивном режиме, запрашивая имя песочницы и т. д.
другой вариант, который я рассмотрел, - написать псевдонимы и добавить их в профиль каждого пользователя.
и запустить его с
теперь это имеет для меня больше смысла
Я думаю, что это проблема типа "нельзя делать" ...
Во-первых, вы не захотите использовать этот скрипт из-за выхода 0 в конце.
Во-вторых, ни один дочерний процесс unix не может напрямую изменять среду родительского. Иначе возможны всякие безумства.
Не могли бы вы добавить что-нибудь в их среду с помощью профиля по умолчанию или файлов bashrc, или вы могли бы написать оболочку для той программы, которую они пытаются запустить?
Позвольте мне подробнее остановиться на концепции «обертки».
Допустим, вы хотите запустить программу Snoopy с PROD или DEV в переменной окружения "OPTIONS" в зависимости от того, хотите ли вы производство или разработку. ЕСЛИ он не установлен, скажем, snoopy делает что-то нелепое, например стирает базу данных для производства и разработки ...
переименуйте snoopy в snoopy.bin (или .snoopy.bin)
затем поместите сценарий в то же место с именем "snoopy", который содержит следующее:
#!/bin/sh
export OPTIONS
case "$OPTIONS"
in
PROD) ;;
DEV) ;;
*) OPTIONS=DEV ;;
esac
#the binary is actually named snoopy.bin
exec "$0.bin" "$@"
Если вы не хотите испортить фактический файл, поместите этот сценарий где-нибудь в файловой системе, которая будет впереди фактической программы отслеживания в пользовательском PATH и будет иметь полный путь к двоичному файлу в инструкции exec сценария ...
Ответ - поиск. Sourcing позволяет включать переменные в скрипт в ток оболочка, но никогда не является ее родителем. Это правда, вы должны быть осторожны, чтобы не использовать какую-либо команду выхода или что-то подобное, потому что это закроет вашу текущую оболочку.
Вы можете создать скрипт с помощью символа «.», Т.е.
. ./myscript.ksh
Может, если попробуешь ...
#!/bin/bash
mknod fifo p
(
echo 'value' > fifo &
)
VARIABLE=`cat fifo`
rm fifo
Это не совсем экспорт переменных, но он может обеспечить базовую связь с родительским процессом.
Хорошо, не смейся сейчас. Очень быстрое и очень грязное решение - добавить
echo "Please copy and paste this command:"
echo ""
echo "export BIN=\"$BIN\""
к вашему сценарию.
Другой подход. Просто exec подчиненный $ SHELL в вашем скрипте, возможно, с другим запросом (измените $ PS1, чтобы уведомить пользователей, в какой среде они работают, чтобы уменьшить путаницу).
Другой подход (моя любимая). Пользователи забывают исходный код вашего скрипта, почему? Поиск поставщиков - это точно стандартный путь. Может быть, хороший способ напомнить им - удалить первую строку (#!/bin/sh) а потом chmod a-x Это. После этого он все еще может быть получен, но, очевидно, не может быть выполнен по ошибке.
Rant: В общем, я чувствую, что у вас вообще возникла странная идея. Может быть, это не странно ... Я бы сказал, что стиль несколько не-Unix. Мне никогда в жизни не нужно было экспортировать среду для родителей. Однажды я видел похожую ситуацию - войдите в .profile с вопросом, какую из трех разных сред установить для одной учетной записи oracle. Плохая идея, в конце концов оказалось, что пользователи предпочли перейти на sudo (они сделали sudo на трех разных учетных записях oraxxx). Могу я спросить, чего вы пытаетесь достичь?