Обе командных строки являются портативными. И оба имеют тот же эффект.
Относительно 2-го: В случае, если $foo
сбои, echo 0
не оценен, таким образом echo $?
печатает статус выхода последней команды - т.е. $foo
.
Логические операторы левоассоциативны, т.е. 2-я командная строка эквивалентна:
$ { $foo && echo 0 } || echo $?
(где первое $
обозначает приглашение оболочки),
Командный язык Shell стандартизирует списки команд, ассоциативность оператора и так далее.
Разделите 2.9.3 из Командного языка Shell, также указывает семантику статуса выхода && оператора:
Статус выхода
Статус выхода И список должен быть статусом выхода последней команды, которая выполняется в списке.
Относительно Вашего постскриптума: Да, POSIX не позволяет его.
Если получатель имеет split
, затем можно сделать:
tar -cvf - ~/batch/ | gzip |
ssh recipient 'cd /destination &&
split --bytes=1024m - batch.tar.gz.seg'
В то время как комментарий, который Вы упоминаете, действительно относится к scp и ssh, читающему из STDIN, это не точно Ваш случай здесь. Причина split
: это не пишет в STDOUT. Таким образом, даже если Вы добавите больше каналов, то Вы не получите данные там. Stephane предлагает правильную вещь в своем ответе выше: ничего не храните на источнике, поскольку он имеет недостатка свободного места, просто пакет, gzip, и передайте данные; и затем сделайте разделение на принимающем конце, где размер блока имеет значение.
Ваше сообщение, на которое ссылаются, описывает проблему хорошо: Поскольку Вы используете канал, Вы не копируете файлы, а скорее перенаправляете стандартные потоки. И scp
не правильный инструмент для того (это для копирования файлов), ssh
правильная программа: Вы перенаправляете поток к ssh
стандартный вход и это произведут тот вход на удаленный хост и подадут его к стандартному входу указанной команды:
local$ tar -cvzf - ~/batch/ | ssh target 'split --bytes=1024m - batch.tar.seg'
Обратите внимание, что я добавил, что сжатие отмечает 'z' к опциям tar, возможно, затем разделение не нужно вообще.