Должен ли я использовать расширения * .sh и * .rb для всех моих сценариев?

Question

У меня есть куча свернутых вручную исполняемых скриптов в моем каталоге $ HOME/bin. Некоторые написаны на bash, некоторые на Ruby. У всех них есть строка shebang вверху, указывающая оболочке, какой интерпретатор использовать (в моем случае bash или Ruby).

Мне интересно, лучше ли добавлять в эти сценарии расширения файлов, чтобы указать, на каком языке сценариев они написаны? Например, скрипты в Ruby будут иметь суффикс * .rb, а скрипты bash будут иметь суффикс * .sh.

В настоящее время эти сценарии имеют простые имена без расширения файла.

Какая лучшая практика?

Answer 1

Ну, как и большинство вещей в жизни: это зависит от ваших потребностей.

Вы заявили, что эти сценарии находятся в каталоге bin, и я предполагаю, что эти сценарии должны вызываться из командной строки. Как пользователь, я считаю раздражающим, если мне нужно набрать bla.ksh или foo.bash. Также, если кодер решит перейти к другому интерпретатору, имя команды также изменится, и мне придется изменить другие сценарии, использующие эти инструменты - очень раздражает, даже если пользователь и кодер - это один и тот же человек.

Но с другой стороны, я использую расширения, такие как .sh или .tcl, в моих каталогах сборки проекта. Таким образом, я могу использовать функции make для развертывания файлов в каталогах назначения, но на этом этапе я удаляю суффикс файла.

Answer 2

Вы можете использовать подстановочные команды, такие как ls *.rb или cp *.sh если хотите организовать свои сценарии в будущем.

Начни рано или пожалеешь позже, на мой взгляд.

Редакторы, такие как vim , также смогут применять правильную подсветку синтаксиса на основе shebang или расширения файла.

Это также может быть достигнуто с помощью моделей в различных редакторах. Например, для VIM:

# vim: ft=sh

Answer 3

Очевидно, есть некоторые различия между исполняемыми файлами в каталогах bin и редактируемыми "исходными" файлами.

• Для исходных файлов полезно иметь суффикс, чтобы вы могли видеть, что к чему, и помочь некоторым менее интеллектуальным инструментам, которые не могут сканировать #! линия.
• Для модулей они используются только связанным набором программ, каждая из которых использует один и тот же интерпретатор (или не интерпретатор), и в таких случаях принято включать .pm , .sh или .so .
• Для исполняемых программ его имя является частью "контракта на программирование", по которому пользователи и другие скрипты вызывают его. Важно, чтобы имя не менялось, даже если реализация меняется; так очевидно, что имя файла не должно иметь суффикса

В случае скомпилированной программы различие между "исходным" и "исполняемым" очевидно: одно содержит исходный код, другое содержит машинный язык или интерпретируемый байт-код. В случае сценария нет очевидного различия, но команда make поддерживает условное разделение между "исходным кодом для сценария" и "исполняемой версией сценария": его "компилятором" по умолчанию для "сценария оболочки" является просто cp .

Я бы порекомендовал сохранить отдельный каталог $HOME/source , а также:

• хранить символическую ссылку, например, сделанную ln -s ../source/foo.sh $HOME/bin/foo ; или же
• скопируйте их вручную после внесения изменений (и тестирования), используя install -m 755 foo.sh ../bin/foo ; или же
• использование правила Makefile для проверки синтаксиса перед копированием исходного файла из $HOME/source в $HOME/bin

Сноска: модуль сценария оболочки может использоваться только другим сценарием оболочки и изменяет внутренний контекст этого сценария с помощью . или source встроенные команды. Это отличается от исполняемого скрипта, который (как и любая программа) запускается как отдельный процесс и не может изменять свой родительский процесс. Как грубое соглашение, модули идут в /usr/lib/name_of_program/name_of_module.sh тогда как команды идут в /usr/bin/name_of_command (без суффикса).

Answer 4

Это необязательно. Ядро уже проинформировано о правильном используемом интерпретаторе (#! строка), и все популярные текстовые редакторы тоже читают его, поэтому добавление расширения ничего не даст, только увеличит скорость набора текста. Единственный раз, когда исполняемая программа имеет расширение, это когда оно каким-то образом важно (для программы, пользователя или обоих).

---

Модули и библиотеки, с другой стороны, почти всегда имеют расширения (.rb для модулей Ruby, .so для общих библиотек ELF и т.д.).