Получите полный путь из сценария Bash

Кажется, что Вы пропускаете определение для макро-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:.

3
09.10.2012, 16:52
4 ответа

Необходимо смочь сделать это.

  • Параметр за 0$ расширяется до полного пути (включая имя) сценария, поскольку это было вызвано.
  • Встроенный тест функции оболочки (или []) может протестировать, если путь является символьной ссылкой с помощью-L
  • ls -l, если относится символьная ссылка, даст одну строку вывода с истинным путем как заключительное поле.

Это достаточно, чтобы Вы обнаружили местоположение источника. Конечно, это могло бы быть символьной ссылкой, которая потребует, чтобы Вы сделали это рекурсивно...

-1
27.01.2020, 21:32
  • 1
    Какой ln делает то, что Вы упомянули в 3. точка? Мой ln на Linux от coreutils пакета нет. Это отображает сообщение об ошибке: “ln: не удалось создать символьную ссылку './bar': Файл существует”. (Где “панель” является символьной ссылкой на “нечто”, любой регулярный файл или каталог.) –  manatwork 09.10.2012, 17:14
  • 2
    Возгласы! Предназначенный ls -l. Опечатка исправлена. –  itsbruce 09.10.2012, 17:56
  • 3
  • 4
    Ни одно из этого не хорошая идея. Я думал бы, что выделение потребности в рекурсии будет ключом к разгадке этого. –  itsbruce 09.10.2012, 21:12

Я не вспоминаю, где я получил это, таким образом, я могу правильно приписать, но я использовал это в течение долгого времени для получения "канонического" пути к сценарию, который я выполняю. Каноническим я имею в виду полный путь без"." или ".." в нем.

CANON=$(cd -P -- "$(dirname -- "$0")" && printf '%s\n' "$(pwd -P)/$(basename -- "$0")")

Если я должен буду, то я буду использовать базовое имя и dirname на $CANON для получения тех значений.

1
27.01.2020, 21:32

Переменная $0 содержит название программы. Сделать

cd $(dirname $( readlink $0) )

измениться на каталог, в котором находится программа.

Да, $0 может быть проблематичным, если используется в общей ситуации. Я думаю, что с помощью него для собственная работа в конкретной ситуации, где набор ясно определяется, прекрасна.

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

0
27.01.2020, 21:32
  • 1
    Это нисколько не надежно или стандартно - посмотрите Bash FAQ 28. –  jw013 09.10.2012, 17:04
  • 2
    При выполнении символьной ссылки, а не исходного сценария 0$ будут путем к символьной ссылке, не оригиналом. –  itsbruce 09.10.2012, 17:08
  • 3
    @itsbruce: да, Вы правы! –  January 09.10.2012, 17:17
  • 4
    @jw013 я думаю, что это - спорный вопрос, учитывая эту конкретную установку. Я пытался объяснить это теперь в ответе. –  January 09.10.2012, 17:26
  • 5
    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%/*}

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

1
27.01.2020, 21:32

Теги

Похожие вопросы