Документ здесь обрабатывается в локальной системе, а не в удаленной системе. Он предоставляет входные данные для локальной команды tar, но не читает со стандартного ввода.

Каждый процесс может иметь стандартный ввод, подключенный только к одному месту. Он может исходить из heredoc или из конвейера, но не то и другое одновременно.

теперь, если у вас была нормальная оболочка, мы могли бы скопировать исходный стандартный ввод в другой файловый диск перед настройкой удаленного heredoc, но поскольку все это вступило в игру из-за того, что у вас необычная оболочка, все ставки сняты, если мы не сможем идентифицировать эту оболочку, чтобы рассуждать о ее конкретном поведении.

...кстати, пробовали ли вы проверить систему с нетипичным поведением, чтобы попытаться выяснить основную причину? Есть ли успех в этих усилиях?

Если проблема связана с кавычками, почему возникают проблемы с исходной командой? В команде, которую вы отправляете по SSH, нет кавычек.

@Barmar выше — это упрощенная версия: в реальном сценарии я читаю значения как переменные из файла конфигурации .json (например, «/some-path/» — это переменная с корневым каталогом сервера в ней).

@CharlesDuffy, система с нетипичным поведением является стандартным хостом WP Engine, поэтому я, вероятно, мало что могу сделать, чтобы они что-то изменили, но мне интересно, почему они удаляют кавычки таким странным образом.

Стоит это выяснить. Если они передают контент напрямую в оболочку, мы можем выяснить, каково поведение этой оболочки. Если они используют какой-то собственный код, чтобы попытаться выполнить синтаксический анализ в стиле оболочки (возможно, как попытка найти команды, отправленные обычным вредоносным ПО или чем-то подобным — экосистема WordPress является популярной целью атак), прежде чем контент будет передан фактическому оболочка... ну, опять же, мы не сможем найти хорошее обходное решение, пока не будем точно знать, над чем работаем.

Зачастую файлы sshd_config доступны для чтения всем — если в них есть ForceCommand, вы сможете прочитать их даже из своей непривилегированной учетной записи пользователя.

Кстати, если у вас есть правильный ответ на вопрос, который был задан при написании этого ответа, неправильно редактировать вопрос таким образом, чтобы сделать ответ недействительным позже (здесь вы можете найти людей, ссылающихся на вопросы, которые изменяются таким образом. способы как «вопросы-хамелеоны»). Нажмите кнопку «Принять» и задайте новый вопрос для нового случая.

Если бы ваша удаленная оболочка была bash (а ваша локальная оболочка была bash 5.0 или новее), я бы предложил tar -pzcf - example.txt | ssh [email protected] "cd ${root_path@Q} && tar -zxf -". Или, лучше, tar -pzcf - example.txt | ssh [email protected] "tar -C ${root_path@Q} -xzf -"

Кстати, если вы добавите set -x; к удаленной команде, например, tar -pzcf - example.txt | ssh [email protected] "set -x; tar -C ${root_path@Q} -xzf -", это будет считаться честью? (Это должно привести к тому, что удаленная оболочка напечатает сообщение журнала с описанием переданных ей аргументов tar).

Я не уверен, что первый вариант будет работать так, как написано сейчас: вы запускаете bash со стандартным вводом, подключенным к временному файлу с содержимым heredoc. Как tar получит дескриптор файла на исходном стандартном вводе? Если вы сохранили копию исходного fd, это должно сработать, но у IIRC у ОП был предыдущий вопрос, подразумевающий, что их удаленная оболочка по умолчанию была чем-то необычным и удивительным для подмножества систем, на которых им нужно было иметь возможность запускать код.

О, ты прав!

Так что им, вероятно, нужно ssh server bash -c 'cd blah && tar -zxf -'

Перефразируя Барби: «Распределенные вычисления — это сложно!»

кивок. Если это GNU tar, они могут даже отказаться от cd и использовать tar -C blah -xzf -.

BSD (например, MacOS) tar также имеет это, так что, вероятно, большинство tar в дикой природе. Хотя, если оболочка по умолчанию несовместима с его исходной командой, кто знает, какой у нее tar?

Я бы, наверное, пропустил здесь bash -c; Целью явного запуска bash было получение хорошо понятного парсера, но поскольку мы не знаем, что такое внешняя оболочка (но знаем, что она не POSIX-y), и поэтому не можем надежно создавать кавычки, предназначенные для получения данные, проходящие через него, возможно, будут лучше, если команда будет максимально простой (не зависящей ни от чего, кроме разделения на пробелы).

Тогда мы, по сути, вернулись к исходной команде, за исключением того, что мы заменили cd blah && tar на tar -C blah.

Но я упростил результат вот так.

В предыдущем вопросе ОП были вложенные кавычки, которые часть удаленных систем ОП проанализировала неправильно. Здесь их нет, поэтому нам не понадобится обходной путь для обработки несовместимых котировок. Я думаю, они взяли решение и попытались применить его за пределами проблемной области, для которой оно предназначалось.

Существует множество вариантов использования sudo и ssh, при которых может быть чрезвычайно сложно правильно выполнить цитирование и экранирование (худшим может быть сочетание ssh hostname sudo ...). Я, вероятно, разместил ответ в Unix & Linux, где решением был документ здесь. Я обычно рекомендую скопировать скрипт на пульт, а затем выполнить его по ssh, а не пытаться все объединить. К сожалению, обычно говорят, что это невозможно.

Когда удаленная оболочка — bash, я считаю ssh somehost "$(declare -f funcname); $(declare -p var1 var2 var3); funcname" вполне надежным решением (при условии, что функция funcname зависит от переменных var1, var2 и var3).