Автоматическая передача файлов между двумя Linux-машинами
Команда execзаменяет текущий процесс оболочки процессом, полученным в результате выполнения данной команды. Без execуправление будет возвращено ожидающему сеансу оболочки после завершения команды. С помощью execтекущая оболочка заменяется, поэтому с этого момента дальнейшие команды не будут выполняться из вашего сценария.
Файл ~/.xinitrcпредставляет собой сценарий оболочки. Он запускает оконный менеджер(twmв вашем случае )и, возможно, другие клиенты X11, которые вы хотите запустить изначально (, например xtermили какой-либо другой терминал, и xeyes, очевидно ). Для этого сценария нет специального синтаксиса, за исключением того, что он должен быть допустимым сценарием (, так как он запускается интерпретатором сценариев оболочки ).
В первом примере вы используете
exec xterm
Это заменяет текущий процесс оболочки на xterm. Без execу вас был бы точно такой же видимый эффект, но скрипт .xinitrcзависал бы в фоновом режиме, ожидая завершения xterm, прежде чем завершиться сам (, так как это был последний команда в файле ).
Обратите внимание: если бы вы сделали exec twm, оболочка заменила бы себя на twm, что означает, что она не сможет выполнять другие команды в сценарии. Вот почему вы вместо этого запускаете twmкак фоновый процесс (с &в конце ).Сон предназначен для того, чтобы twmмог правильно запуститься перед запуском терминала. Я не думаю, что это строго необходимо. На самом деле, если вам не нужны декорации окон или возможность перемещать окна или изменять их размер, нет необходимости даже запускать twmили любой другой оконный менеджер (, по крайней мере, для запуска в полноэкранном режиме xterm).
Во втором примере вы используете
exec WINDOWING=x11 /usr/bin/kodi -geometry +0+0
Теперь команду execнельзя использовать для установки таких переменных среды. Вместо этого вы должны установить и экспортировать WINDOWINGпеременную до вызоваkodi:
export WINDOWING=x11
exec /usr/bin/kodi -geometry +0+0
Основным недостатком этой схемы является то, что хост B не может узнать, когда безопасно копировать файлы. Что, если A записывает файл в общий каталог NFS -, а хост B получает доступ к этому файлу до того, как он будет полностью записан? Хост B скопирует частичный файл, и если эта (частичная )копия будет успешной, он удалит весь файл, включая ту часть, которую он не скопировал, потому что хост A не еще не закончил писать.
Тем не менее, это кажется довольно простым применением для rsync. Прочтите страницу man, особенно вариант --partial, возможно, вариант --checksumи , особенно предостережение в разделе, посвященном параметру --remove-source-files. Предлагаемый обходной путь использования имен файлов, таких как *.new, когда хост A записывает файлы для копирования хостом B, а затем переименование файлов .newв любое предполагаемое имя, может сработать для вас. Переименование в пределах одной файловой системы, как правило, является атомарной операцией, поэтому хосту B просто нужно набраться терпения и игнорировать любые файлы *.new. Как только они будут переименованы, хост B передаст их при следующем запуске задания cron.
Я бы предложил rsnapshot .
это базовый скрипт perl, скрипты уже сделаны за вас, просто отредактируйте его /usr/local/etc/rsnapshot.confфайл и укажите источник и место назначения для копии.
Затем вы запускаете/usr/local/bin/rsnapshot— я думаю, что исполняемый файл помещается туда
Чтобы запустить это автоматически:crontab -eи сделать что-то вроде
0 12 * * * /usr/local/bin/rsnapshot daily
Синтаксис crontab:
minute hour day_of_month month day_of_week
согласно моему синтаксису crontab, будет запускать все, что указано, в 12 :00 вечера каждый день
0 22 * * 2 /usr/local/bin/rnsapshot daily # will run at 8:00pm only every Monday
прочтите инструкции rsnapshot относительно ежедневного входного аргумента perl-скрипта rsnapshot
rsnapshot может копировать между чем угодно, если вы настроите все необходимое [описано в инструкции]