shebang и path

Почему shebang нужен путь?

Неправильно

#!ruby 

Верный

 #!/usr/local/bin/ruby #!/usr/bin/env ruby 

Операционная система должна иметь информацию о пути для зарегистрированной команды и почему она все еще ожидает ее предоставления?

  • Как вы делаете деловые заявления с диапазонами
  • Как подключить вывод netcat? Проблемы с xargs и кавычками
  • Скрипт не выполняется в соответствии с ожиданием
  • Прямой рекурсивный вывод сценария оболочки для каждого подкаталога, а не родительского каталога
  • Секунды и даты прыжка
  • Формат изменения даты в unix
  • Сохранение вывода команды в переменной оболочки
  • Подождите, пока разветвленный процесс откроет окно
  • 5 Solutions collect form web for “shebang и path”

    Вероятно, чтобы ядро ​​было проще. Я не думаю, что ядро ​​когда-либо ищет ваш путь к поиску исполняемого файла. Это обрабатывается библиотекой C. #! обработка выполняется в ядре, которое не использует стандартную библиотеку C.

    Кроме того, я не думаю, что у ядра есть представление о вашем пути. $PATH – это переменная среды, и только процессы имеют среду. Ядро этого не делает. Я полагаю, что он мог получить доступ к среде процесса, который выполнял exec, но я не думаю, что в настоящее время в ядре когда-либо обращаются к таким переменным среды.

    Вы можете получить семантику поиска PATH с помощью env , так что:

     #!/usr/bin/env ruby 

    имеет семантику, которую вы хотели бы

     #!ruby 

    Причина, по которой в зависимости от PATH не считается хорошей практикой, заключается в том, что скрипт не может делать никаких предположений о содержимом переменной среды PATH, нарушая «последовательную модель зависимостей» двоичных файлов, где

    1. /bin содержит исполняемые файлы, необходимые во время загрузки;
    2. /usr/bin содержит другие исполняемые файлы, используемые установкой ОС;
    3. /usr/local/bin содержит исполняемые файлы, установленные системным администратором, которые не являются частью базовой ОС.
    4. ~/bin содержит собственные исполняемые файлы пользователя.

    Каждый уровень не должен предполагать существование двоичных файлов позже в последовательности, которые являются более «прикладными», но могут раньше полагаться на двоичные файлы, которые являются более «фундаментальными». И переменная PATH имеет тенденцию работать от приложения к фундаментальному, что является противоположным направлением к естественной зависимости выше.

    Чтобы проиллюстрировать проблему, спросите себя, что произойдет, если скрипт в ~/bin вызывает скрипт в /usr/local/bin который вызывает Ruby? Должен ли этот сценарий зависать от установленной версии ОС в /usr/bin/ruby или на личной копии, которую пользователь имеет в ~/bin/ruby ? Поиск PATH дает непредсказуемую семантику, связанную с последней (возможно, ~/bin/ruby – это сломанная символическая ссылка), при этом выпекайте путь #! дает первое.

    На самом деле нет никакой другой независимой от платформы «операционной системы … информации о пути для зарегистрированной команды», поэтому проще всего настаивать на том, что путь указан в #! ,

    Я считаю, что вы можете указать альтернативный интерпретатор, если вам нужно или хотите. Например:

     #!/home/user/myrubyinterpreter 

    Чаще всего встречаются сценарии оболочки:

     #!/bin/bash #!/bin/sh #!/bin/dash #!/bin/csh 

    Из книги Classic Scripting :

    Сценарии оболочки обычно начинаются с #! /bin/sh #! /bin/sh . Используйте путь к POSIX-совместимой оболочке, если ваш /bin/sh не совместим с POSIX. Есть также некоторые низкоуровневые «gotchas», на которые следует обратить внимание:

    • Вы должны знать полный путь к интерпретатору, который должен быть запущен. Это может предотвратить переносимость между поставщиками, поскольку разные поставщики размещают вещи в разных местах (например, /bin/awk против /usr/bin/awk ).

    Есть и другие причины, но с точки зрения безопасности я бы никогда не хотел, чтобы сценарий делал предположения о правильном пути. Что, если это неправильно, и работает неправильная оболочка или интерпретатор? Тот, который был вставлен злоумышленником? Или что, если он полагается на определенную оболочку и выйдет из строя, если используется неправильная оболочка?

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

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

    Interesting Posts

    настроить dhcp-клиент, не принимая записи сервера имен

    Команда SSH ведет себя по-разному в Expect Script

    Безопасное хранение необработанных изображений на USB-накопителях

    Выполнить команду, основанную на частоте stdout

    размещение слов, соответствующих ключу в одном ряду

    Почему команды cat, grep и другие команды не могут понять файлы, начинающиеся с знака «минус»?

    Как разбить аудиофайл на несколько?

    Запрос на отображение файлов UNIX, созданных на определенную метку времени

    chown не работает через скрипт

    Фоновый процесс сценария по-прежнему сохраняется после закрытия терминала

    Будут ли компилировать модули make-kpkg?

    _update-rc.d vncserver-x11-serviced defaults_ COMMAND = Между запуском службы rc.local и mountkernfs существует цикл. ERROR

    Является ли /var/crash/.lock безопасным для удаления или его следует сохранить?

    Как использовать команду задания и просмотреть результаты

    Альтернатива не KDE для KNotes?

    Linux и Unix - лучшая ОС в мире.