~/.ssh/config:
Host REMOTEHOST
...
ForwardX11 yes
/etc/ssh/sshd_config:
X11Forwarding yes
bash:
$ xclip -o | ssh REMOTEHOST 'DISPLAY=:0 xclip -i'
Задайте PATH
явно.
Если вы делаете это из своего сценария, вы можете добавить к текущей настройке $PATH
, тогда вы будете уважать все, что там есть, и просто добавите то, что вы хотите убедиться, что оно не пропало:
#!/bin/bash
PATH=$PATH:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin
...
Возможно, было бы более уместно установить PATH
в конфигурации crontab (вы можете установить там переменные окружения ), поскольку, по сути, вы работаете над недостатком самого cron, так что, возможно, исправление его в cron имело бы больше смысла, чем изменение вашего скрипта.
Если вы установите его в cron, вам нужно будет завершить настройку PATH
, так как вы не можете оттуда ссылаться на его текущее значение:
# my user's crontab
PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin
0 2 * * * /usr/local/bin/my2amjob.sh
(Вам может понадобиться немного другой порядок каталогов, в зависимости от того, устанавливали ли некоторые из ваших систем или вы сами «переопределения» для более простых версий, установленных в каталогах, которые перечислены ниже в $PATH
, но проверьте, что в настоящее время установлено в ваших системах. и посмотрите, сможете ли вы примирить это.)
Надеюсь, это решит вашу проблему.
Should system-wide PATH ever change, I might need to manually update all those lines.
Честно говоря, я бы не слишком беспокоился об этом. Ваши дистрибутивы всегда будут устанавливать свои двоичные файлы в /usr/bin
, /usr/sbin
, /bin
или /sbin
, поэтому вы всегда сможете получить к ним доступ без каких-либо изменений пути. Дистрибутивы давно поняли, что обновление $PATH
для включения новых каталогов — это кошмар, поэтому они избегали этого, вместо этого добавляя символические ссылки или скрипты-оболочки в основные каталоги bin
.
Для программного обеспечения, которое вы устанавливаете самостоятельно и которое рекомендует обновить $PATH
, я бы рекомендовал делать то же самое, создавая символические ссылки или скрипты-оболочки в /usr/local/bin
и избегая изменений в $PATH
, если это возможно.
В дистрибутивах Linux также предпринимаются некоторые шаги, чтобы сделать эти различия $PATH
проблемой прошлого.
Во-первых, это/usr
попытка слияния , которая превращает /bin
в символическую ссылку на /usr/bin
и /sbin
в символическую ссылку на /usr/sbin
.Все двоичные файлы устанавливаются под/usr
(проще для упаковщиков ), но скрипты, которые по-прежнему ссылаются на них через какой-то абсолютный путь, например /bin/mytool
или /sbin/mytool
, будут продолжать работать через символические ссылки. Это было принято дистрибутивами, такими как Fedora и ArchLinux, а другие дистрибутивы, такие как Debian и Ubuntu, в настоящее время проходят этапы внедрения.
ArchLinux, похоже, пошел еще дальше и объединил sbin
и bin
вместе . Таким образом, в современном ArchLinux, где было принято слияние, вы можете обратиться к двоичному файлу по любому из четырех возможных абсолютных путей, и вы их найдете. Остается посмотреть, примут ли другие дистрибутивы это второе слияние.
Наконец, вы можете рассмотреть более современные альтернативы cron. Cron имеет довольно много особенностей, таких как пустая среда, с которой вы работаете, а также использование электронной почты для вывода команды (вместо использования системы ведения журнала )и неудобного экранирования командной строки.
Вы упомянули Ubuntu и ArchLinux, обе из них поддерживают системные таймеры, встроенные -без необходимости установки каких-либо пакетов.
Вы можете проверить вики ArchLinux, где есть отличные статьи о том, как их использовать. В частности, вы можете захотеть проверить , используя systemd Timers в качестве замены cron , который имеет специальные рецепты, которые могут быть очень полезны для вашего конкретного случая использования.