Официальный стандарт / соглашение для расширения файла для сценариев оболочки к источнику


11

Мне было интересно, существует ли соглашение для расширений типов файлов для сценариев оболочки, которые вы хотите использовать вместо запуска. Например:

  1. Если я хочу запустить этот скрипт в подоболочке.

    ./script.sh 
  2. Если я хочу не забыть запустить этот скрипт из текущей оболочки.

    . script.source 

Есть ли соглашение (например, POSIX) для типа файла во втором примере? Что-то вроде .sourceили .sourceme?


Обновить

Этот вопрос не задает ни о каком мнении. Я четко заявил, что хотел бы знать, существует ли стандартизированное расширение файла для этого вида сценариев. Этот вопрос еще менее основан на мнениях, чем этот хорошо принятый вопрос по аналогичной проблеме ( Использовать расширение .sh или .bash для скриптов bash? ).


1
Некоторые люди думают, что сценарии оболочки, которые могут запускать исполняемые файлы (т #!/bin/sh.
Е.

1
Зависит от того, для чего это нужно, вы можете иметь env, rc, conf и т. Д.
123

1
@ 123 это зависит, иногда , когда вы что - то построить Thats полезно и положить его в $PATH, вы пришли , чтобы использовать все время, так что его , как, ps, ls, curlи все другие команды, то вы начинаете функции завершения сборки оболочки вокруг него, я считаю , это нормально, чтобы удалить расширение. Но да, когда вы создаете сценарий оболочки, который сам по себе не является исполняемым, я бы не chmod +xстал его называть script.sh. также я часто назначаю расширение просто потому, что если я не сделаю этого, я не получу подсветку синтаксиса в моем редакторе.
the_velour_fog

5
Там нет конвенции. Если вы работаете в компании или участвуете в совместном проекте (например, opensource), у вас могут быть местные стандарты, но де-факто не существует соглашения.
Стивен Харрис

1
Слово «соглашение» (значение № 2), вероятно, ведет к «основанным на мнении» ответам. Спецификация открытой группы для источника не применяет никаких стандартов именования.
Джефф Шаллер

Ответы:


18

Я бы использовал .sh(для файлов на shязыке POSIX , .bashдля несовместимых с sh bashфайлов, то есть расширение идентифицирует язык, на котором написан скрипт) для файлов, предназначенных для получения (или, в более общем случае, не предназначенных для выполнения), и нет расширения для файлов, которые должны быть выполнены.

Вы также можете добавить:

#! /bin/echo Please-source

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


Вы также можете выйти, если сценарий не получен ( stackoverflow.com/q/2683279/4694621 )
Mateusz Piotrowski

4

Что касается исходных файлов, я думаю, что лучший способ - это .conf для файлов, которые настраивают ваш скрипт, и .shlib или .shlibs для файлов, которые имеют функции или другие утилиты.

Если вы хотите запретить запуск сценария с неверной оболочкой, и вам не достаточно hashbang, вы можете использовать это:

if [ "$(readlink "/proc/$$/exe")" != "/bin/bash" ]; then
      echo >&2 "CAUTION: Wrong interpreter detected. You must use bash."
      exit 1
fi

1
Если вы собираетесь использовать Линукс /proc/$$/exe, вы можете также сделать это как case $(readlink "/proc/$$/exe") in */bash)..., хотя здесь, я бы просто использовать: if [ -z "$BASH_VERSION" ]. ( echoдолжно быть echo >&2). (Мне нравятся вы .confили .shlibs(но для sh-файлов) расширения, хотя это может не помочь подсветкам синтаксиса, которые полагаются на расширение).
Стефан Шазелас

Да, я вижу это .shlibs, в какой-то программе, которую я не загружаю, но я не помню, поэтому я начал использовать это. Большое спасибо за совет, я отредактирую вопрос с версией readlink намного более красивой. ;-)
Лучано Андресс Мартини

@ StéphaneChazelas Подсветка синтаксиса может запускаться через метаданные в самих файлах (по крайней мере для Emacs и Vim), поэтому выбор расширения имени файла в этом отношении не имеет значения.
Кусалананда
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.