Чому віддалена команда SSH отримує меншу кількість змінних середовища, а потім при ручному запуску? [зачинено]

У мене є команда, яка працює добре, якщо я сшу на машину і запускаю її, але не вдається, коли я намагаюся запустити її за допомогою віддаленої команди ssh, наприклад:

ssh user@IP <command>

Порівнюючи вихід "env" за допомогою обох методів, перезавантажується в різних середовищах. Коли я вручну входжу в систему на машині і запускаю env, я отримую набагато більше змінних середовища, ніж тоді, коли запускаю:

ssh user@IP "env"

Будь-яка ідея чому?

Існують різні типи оболонок. Оболонка виконання команд SSH - це неінтерактивна оболонка, тоді як ваша звичайна оболонка - або оболонка для входу, або інтерактивна оболонка. Опис випливає з man bash:

       Оболонка для входу - це та, чий перший символ аргументується
       нуль - це - або починається з опції --login.

       Інтерактивна оболонка - це запускається без необов'язкових варіантів
       аргументи і без параметра -c, стандартний вхід якого
       і помилка обоє підключені до клем (як визначено)
       by isatty (3)), або той, що розпочався з опції -i. PS1 є
       set і $ - включає i, якщо bash є інтерактивним, що дозволяє a
       скрипт оболонки або файл запуску для перевірки цього стану.

       У наступних параграфах описано, як bash виконує його
       файли запуску. Якщо будь-який з файлів існує, але не може бути
       читати, bash повідомляє про помилку. Тильди розширені у файлі
       імена, як описано нижче в розділі Розширення Tilde в
       Розширення розділу.

       Коли bash викликається як інтерактивна оболонка входу, або як
       неінтерактивна оболонка з опцією --login, спочатку
       читає і виконує команди з файлу / etc / profile, якщо
       цей файл існує. Прочитавши цей файл, він шукає
       ~ / .bash_profile, ~ / .bash_login та ~ / .profile, в цьому
       впорядковує, і читає та виконує команди з першого
       що існує і читається. Опція --noprofile може
       використовувати, коли оболонка починає гальмувати цю поведінку
       ior.

       Коли оболонка входу виходить, bash читає та виконує команди
       з файлу ~ / .bash_logout, якщо він існує.

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

       Коли bash запускається неінтерактивно, для запуску оболонки
       наприклад, скрипт шукає змінну BASH_ENV в
       навколишнє середовище, розширює свою цінність, якщо вона з’являється там,
       і використовує розширене значення як ім'я файлу для читання
       і виконати. Bash поводиться так, ніби наступна команда
       були виконані:
              if [-n "$ BASH_ENV"]; тоді . "$ BASH_ENV"; фі
       але значення змінної PATH не використовується для пошуку
       для імені файлу.

Як щодо пошуку профілю перед запуском команди?

ssh user@host "source /etc/profile; /path/script.sh"

Ви можете виявити , що краще змінити , що ~/.bash_profile, ~/.bashrcабо будь-який інший .

(Як тут (linuxquestions.org) )

Середовище оболонки не завантажується при виконанні віддаленої команди ssh. Ви можете редагувати файл середовища ssh:

vi ~/.ssh/environment

Його формат:

VAR1=VALUE1
VAR2=VALUE2

Також перевірте sshdконфігурацію для PermitUserEnvironment=yesпараметра.

У мене було подібне питання, але врешті-решт я дізнався, що ~ / .bashrc - це все, що мені потрібно.

Однак в Ubuntu мені довелося коментувати рядок, який припиняє обробку ~ / .bashrc:

#If not running interactively, don't do anything
[ -z "$PS1" ] && return

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

В одній з попередніх відповідей було запропоновано використовувати ~ / .bashr_profile тощо .... Я не витрачав на це багато часу, але проблема з цим полягає в тому, що якщо ви шукаєте інший користувач цільової системи, ніж оболонка вихідної системи, з якої ви входите, мені здалося, що це викликає користувача вихідної системи ім'я, яке буде використано для ~.

Просто експортуйте змінні середовища, які ви хочете, вище чека на неінтерактивну оболонку в ~ / .bashrc.