Чому sh (не bash) скаржиться на функції, визначені в моєму .bashrc?

Це я отримую, коли відкриваю термінальний сеанс:

sh: визначення функції імпорту помилок для `read.json '

sh: визначення функції імпорту помилок для `ts-project '

sh не любить ці функції, оскільки вони виглядають так:

read.json(){
   ::
}

ts-project(){
   ::
}

справжнє питання - чому shторкатися / інтерпретувати ці файли? Я на MacOS і бачив це раніше, це така таємниця. Я думаю, що тільки bash завантажує ці файли.

оновлення : bash і sh - це нічого незвичайного. коли я набираю bash в термінал, я отримую це:

alex$ bash
beginning to load .bashrc
finished loading .bashrc
bash-3.2$

коли я набираю shтермінал, я отримую таке:

alex$ sh
sh: error importing function definition for `read.json'
sh: error importing function definition for `ts-project'
sh-3.2$

bash shell bash-functions

— Олександр Міллс
джерело

Можливо, / bin / sh базується на цій системі?

— Джефф Шаллер

ніхто з них не джерело один одного, я виявив, що це була погана практика на важкому шляху. однак ~ / .profile створює спільний файл bash, тож, можливо, shє джерелами файлу .profile?

— Олександр Міллс

Інформація про наявність ~ / .profile-файлу, що джерела спільного файлу, мені здається важливою.

— Джефф Шаллер

Що я мав на увазі під тим, що / bin / sh є bash, це те, що можливо, що це символічно або жорстко посилання на bash. Bash потім емулює sh, але також джерела ~ / .profile. Я просто не знаю, як OSX пакети sh і bash.

— Джефф Шаллер

Вони побудовані з того самого bashджерела, одне з STRICT_POSIX, інше без нього.

— mosvy

Відповіді:

Ця помилка трапляється, коли bashмаскується як оболонка POSIX намагається імпортувати ці функції з оточення, а не під час завантаження їх інтерпретацією файлу, подібного ~/.bashrcчи іншого. Спрощений приклад:

foo.bar(){ true; }; export -f foo.bar; bash --posix -c true
bash: error importing function definition for `foo.bar'

Я bashсподівався не завантажувати функції з оточення в режимі posix, але це робить , і скаржиться лише тоді, коли їх імена містять забавні символи.

Зауважте, що bashтакож буде працювати в режимі posix, коли встановлена змінна POSIXLY_CORRECTабо POSIX_PEDANTICсередовище або коли вона була складена з --enable-strict-posix-default/ STRICT_POSIX.

Останнє , як видається, в разі /bin/shна MacOS (див тут для PRODUCT_NAME = sh), де я очікую цю помилку також тригер при використанні бібліотечних функцій , таких як popen(3)або system(3).

— мосви
джерело

Виправлення: не експортуйте функції в навколишнє середовище. Це баш антифункція, що призвела до (а точніше, просто був) Shellshock, і його слід було зняти, але не тому, що люди нерозумно його використовують. Не будь одним із них.

— R .. GitHub СТОП ДОПОМОГАЄТЬСЯ

Той факт, що імпорт bash функціонує навіть тоді, коли його викликають, sh- це значно погіршило вразливість Shellshock / bashdoor .

— Стефан Шазелас

Дивіться також SHELLOPTS=posixта -o posixінші способи включення режиму posix.

— Стефан Шазелас

Також зауважте, що set -a/ set -o allexportтакож спричиняє експорт всіх функцій bash (і якщо вони викликані як sh, викликає POSIXLY_CORRECTвстановлення та експорт!)

— Stéphane Chazelas

( sh -aпричини POSIXLY_CORRECTвстановлюються та експортуються; set -aпісля того , як shбез -aзапуску не експортується, POSIXLY_CORRECTоскільки це було встановлено раніше -a).

— Стефан Шазелас

Щоб відповісти на частину причин read.jsonі чому ts-projectне є портативними іменами функцій:

Відповідно до стандарту POSIX, визначення функції повинні бути названі по

слово, що складається виключно з підкреслення, цифр та алфавітів з набору переносних символів. Перший символ імені не є цифрою.

Також відомий як ідентифікатор , в C lingo. Або в регулярному вираженні:[_a-zA-Z][0-9_a-zA-Z]*

— user2394284
джерело

Але POSIX не забороняє реалізаціям приймати інші імена для функцій, тому bash не повинен був накладати ці обмеження в режимі POSIX. Імена функцій діляться тим самим простором імен, що і аргументи команд, тому немає ніяких причин приймати що- небудь (наприклад, zsh/ rc/ fish...)

— Stéphane Chazelas

@ StéphaneChazelas: Я знаю, але що означає бути в режимі POSIX, якщо не "пролити всі розширення", як у "не мовчки їх приймати"?

— користувач2394284

@ user2394284 це, звичайно, не означає, що в bash, або він не імпортує функції з навколишнього середовища, перебуваючи в режимі POSIX, чого не вимагає специфікація POSIX ;-)

— mosvy

@mosvy: Так, очевидно, що баш провалився десь по дорозі - я б сказав, що це звичайна оболонка POSIX, яка була б помилкою.

— користувач2394284

Тому я спричинив це те, що я збираю деякі сценарії bash у моєму файлі ~ / .bashrc так:

for f in "$HOME/.oresoftware/bash/"*; do
   . "$f"
done;

тому я просто змінив його на:

for f in "$HOME/.oresoftware/bash/"*; do
  if [[ "$(basename "$0")" != 'sh' ]]; then
      # source only if not using sh
      . "$f"
  fi
done;

тож теоретично, якщо він викликається до shцього часу, він не намагатиметься джерело цих файлів, але не впевнений, що це працює 100% часу.

— Олександр Міллс
джерело