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


20

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

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

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

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


1
Достаточно просто конвертировать из shebang в расширение и обратно с помощью простого скрипта. Так что попробуйте один и исправить это позже, если вам нужно.
Аарон Дж Ланг

Ответы:


9

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

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

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

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

# vim: ft=sh

2
ИМХО, организацию лучше делать по функциям, а не по деталям реализации.
Гравитация

4
@ Grawity: тем не менее, упорядочивание по суффиксу проще, чем приписывание к шебангу ...
Акира

Хотя я согласен с непонятной причиной, большинство редакторов достаточно умны, чтобы прочитать шебанг, чтобы определить тип файла.
Рич Гомолка

10

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

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

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


6

Очевидно, есть некоторые различия между исполняемыми файлами в 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(без суффикса).


3

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


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


вопрос не столько в том, «может ли ядро ​​запустить его, если я не предоставляю суффикс», а в том, «помогает ли он мне». увеличение набранных символов не имеет значения с завершением.
Акира
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.