Я предполагал, что это то же самое, но это не так.
В моем конкретном случае сценарий сборки работает нормально, когда выполняется как ./build.sh из сеанса ssh на сервере сборки, например
$ssh user@host
$./build.sh
но не работает при запуске в качестве аргумента ssh, например:
$ssh user@host /home/user/build.sh
или как это
$ssh user@host ./build.sh
Сам скрипт просто вызывает кучу двоичных файлов, и их сообщения об ошибках не очень полезны для отладки.
Но неважно, что находится в сценарии, если среда такая же, верно? Так в чем может быть разница?
Изменить: не знаю, имеет ли это значение, но описанное поведение происходит в гостевой системе ArchLinux Virtualbox без среды рабочего стола. Я также пробовал то же самое на виртуальной машине Ubuntu18.04 со средой рабочего стола, и сценарий работал правильно в обоих случаях.
Я думаю, что разобрался.
Разница между этими двумя случаями заключается в интерактивной и неинтерактивной оболочке, которые действительно существенно отличаются друг от друга.
Вместо того, чтобы запускать скрипт как $ssh user@host ./build.sh, сработало сначала открыть оболочку входа, вызвав bash -l, как это:
$ssh user@host bash -l ./build.sh
Я не знаю, делает ли он среду выполнения такой же, как запуск скрипта вручную через ssh, но в моем случае это исправило ошибку.
Если вы не укажете программу для запуска, то ssh запустит интерактивную оболочку, для которой будет выделен псевдотерминал.
Если вы укажете команду для запуска, выделения псевдотерминала не будет, что приведет к сбою некоторых команд (особенно тех, которые используют переменную TERM, например, интерфейсы curses).
Вы можете принудительно выделить терминал, используя -t переключатель, проверьте, решает ли это вашу проблему.
Логика такая:
ssh remote_host предполагает, что ваше имя пользователя на вашем локальном компьютере такое же, как и на удаленном, а если ваше имя пользователя отличается на удаленном компьютере, вам необходимо проанализировать имя удаленного пользователя в формате: ssh имя пользователя @ удаленный хост
Нет причины что-то вроде ssh user@IP ./exe.sh не работать, если сам скрипт, разрешения и путь в порядке.