Кажется, что Вы пропускаете определение для макро-ETC_MAILNAME. Также Вы, кажется, выполняете fetchmail как корень, который не рекомендуется. Я получил бы электронную почту поставки exim4 к желаемому узлу и затем настроил бы fetchmail для выборки почты.
Однако я не уверен, почему Вы используете fetchmail и exim4 для тиражирования функциональности, которая доступна в Gmail. Можно настроить это в Forwarding and POP/IMAP
настройки Gmail.
Править: Обычно ETC_MAILNAME заменяют с содержанием /etc/mailname
который должен быть FQDN (Полностью определенное Доменное имя, например, mailer.example.com) Вашего хоста к почтовым целям. Это может отличаться от имени хостов.
Необходимо добавить псевдоним для корня в непривилегированную учетную запись в /etc/aliases
если у Вас уже нет того.
То, что Вы предлагаете сделать путем замены ОТ адреса на электронной почте с адресом средств передачи, перенаправит большинство ответов на почтовый ящик, который делает передачу. Без некоторой специальной обработки я не думаю, что Ваше решение Exim сделает то, что Вы хотите.
Обычно передача отражается в Тематической рубрике. Часто путем добавления префикса как FWD:
.
Необходимо смочь сделать это.
ls -l
, если относится символьная ссылка, даст одну строку вывода с истинным путем как заключительное поле.Это достаточно, чтобы Вы обнаружили местоположение источника. Конечно, это могло бы быть символьной ссылкой, которая потребует, чтобы Вы сделали это рекурсивно...
Я не вспоминаю, где я получил это, таким образом, я могу правильно приписать, но я использовал это в течение долгого времени для получения "канонического" пути к сценарию, который я выполняю. Каноническим я имею в виду полный путь без"." или ".." в нем.
CANON=$(cd -P -- "$(dirname -- "$0")" && printf '%s\n' "$(pwd -P)/$(basename -- "$0")")
Если я должен буду, то я буду использовать базовое имя и dirname на $CANON для получения тех значений.
Переменная $0
содержит название программы. Сделать
cd $(dirname $( readlink $0) )
измениться на каталог, в котором находится программа.
Да, $0
может быть проблематичным, если используется в общей ситуации. Я думаю, что с помощью него для собственная работа в конкретной ситуации, где набор ясно определяется, прекрасна.
В частности, сценарий не должен использовать свой каталог для работы так или иначе, должен полагаться на переменную окружения или файл конфигурации, итак, почему забота о деталях как "кто-то, возможно, переместила сценарий во время, так как Вы запустили его" или как ksh интерпретирует его (учитывая, что мы знаем, что это - сценарий удара).
readlink $0
не произведет вывод, если сценарий не будет символьной ссылкой. Использовать readlink -f
. OTOH вместо $0
, Вы могли также использовать $BASH_SOURCE
. Да, это - конкретный удар.
– pihentagy
12.03.2014, 15:48
Оболочка всегда знает путь к сценарию при нормальных обстоятельствах, потому что это должно было считать его. Обратите внимание, что существуют обстоятельства, где это не верно, например, с setuid сценариями на Ose, которые поддерживают их (не Linux) — но setuid сценарии оболочки являются плохой идеей так или иначе. Самое главное сценарий, возможно, был перемещен между временем, оболочка открыла его и время, Вы пытаетесь сделать что-либо с ним. Поэтому только используйте путь к сценарию, когда не будет никакого беспокойства безопасности или надежности при этом. Пакет программного обеспечения с известной структурой является допустимым вариантом использования.
Путь к сценарию, который был передан интерпретатору оболочки, доступен в специальном параметре $0
. Это может быть относительным путем, поэтому если Вы собираетесь использовать его, сделать это прежде, чем измениться на другой каталог. Можно использовать его, если Вы знаете, что сценарий не будет перемещен тем временем.
С тех пор $0
может быть символьная ссылка, необходимо будет получить ее цель. Нет никакого POSIX способа сделать это, но на Linux (GNU coreutils или BusyBox) и недавний BSD, который можно использовать readlink -f
получить канонический полный путь.
script_path_in_package=$(readlink -f -- "$0")
script_directory=${script_path_in_package%/*}
Обратите внимание, что это ограничивает пути, которыми можно структурировать пакет. Например, Вы не можете поместить сценарий в архитектурно-независимое дерево каталогов и связаться с ним в каждом архитектурно-зависимом дереве каталогов.
ln
делает то, что Вы упомянули в 3. точка? Мойln
на Linux от coreutils пакета нет. Это отображает сообщение об ошибке: “ln: не удалось создать символьную ссылку './bar': Файл существует”. (Где “панель” является символьной ссылкой на “нечто”, любой регулярный файл или каталог.) – manatwork 09.10.2012, 17:14ls -l
. Опечатка исправлена. – itsbruce 09.10.2012, 17:56ls
не хорошая идея. – jw013 09.10.2012, 18:03