Я написал сценарий bash в текстовом редакторе. Какое расширение я могу сохранить сценарий, чтобы он мог работать как сценарий bash? Я создал сценарий, который теоретически должен запускать ssh-сервер. Мне интересно, как заставить скрипт выполняться, когда я нажимаю на него. Я использую OS X 10.9.5.
84
bash myscript
.sh
, но расширение вообще не обязательно. Linux - это не Windows. Программа, которая будет интерпретировать ваш скрипт, определяется в его первой строке, которой и должно быть#!/bin/bash
. Он может даже включать параметры.#!/bin/bash
.Ответы:
Не соглашаясь с другими ответами, существует общее соглашение об использовании
.sh
расширения для сценариев оболочки, но это соглашение не является полезным. Лучше вообще не использовать расширение. Преимущество возможности определить, чтоfoo.sh
это сценарий оболочки из-за его имени, минимально, и вы платите за него потерей гибкости.Чтобы сделать скрипт bash исполняемым, он должен иметь строку shebang вверху:
#!/bin/bash
и используйте
chmod +x
команду, чтобы система распознала ее как исполняемый файл. Затем его необходимо установить в один из каталогов, перечисленных в вашем$PATH
. Если сценарий вызванfoo
, вы можете выполнить его из приглашения оболочки, набравfoo
. Или, если он находится в текущем каталоге (обычно для временных сценариев), вы можете ввести./foo
.Ни оболочка, ни операционная система не обращают внимания на часть расширения имени файла. Это просто часть имени. И, не давая ему специального расширения, вы гарантируете, что любой (будь то пользователь или другой скрипт), который его использует, не должен заботиться о том, как это было реализовано, будь то сценарий оболочки (sh, bash, csh или что-то еще) , сценарий Perl, Python или Awk или исполняемый двоичный файл. Система специально разработана таким образом, чтобы можно было вызывать интерпретируемый скрипт или двоичный исполняемый файл, не зная и не заботясь о том, как он реализован.
UNIX-подобные системы начинались с чисто текстового интерфейса командной строки. Позже были добавлены графические интерфейсы, такие как KDE и Gnome. В настольной системе с графическим пользовательским интерфейсом вы обычно можете запустить программу (опять же, будь то скрипт или исполняемый файл), например, дважды щелкнув значок, который ссылается на него. Обычно это отбрасывает любой вывод, который программа могла бы напечатать, и не позволяет передавать аргументы командной строки; он гораздо менее гибкий, чем запуск из командной строки. Но для некоторых программ (в основном клиентов с графическим интерфейсом) это может быть удобнее.
Сценарии оболочки лучше всего изучать из командной строки, а не из графического интерфейса.
(Некоторые инструменты делают обратить внимание на расширения файлов , например, компиляторы обычно используют расширение для определения языка код написан в:.
.c
Для C,.cpp
. Для C ++, и т.д. Это соглашение не относится к исполняемым файлам)Имейте в виду, что UNIX (и UNIX-подобные системы) не являются Windows. MS Windows обычно использует расширение файла, чтобы определить, как его открыть / запустить. У двоичных исполняемых файлов должно быть
.exe
расширение. Если в Windows установлена UNIX-подобная оболочка, вы можете настроить Windows на распознавание.sh
расширения как сценарий оболочки и использование оболочки для его открытия; В Windows нет#!
соглашения.источник
deploy.sh
(илиdeploy.bash
) и папкаdeploy
с дополнительной логикой развертывания. Если вы просто переименуете скрипт,deploy
это вызовет конфликт имен. Иное наименование файла или папки ухудшает управляемость и, возможно, сортировку файлов (ls
в редакторах и т. Д.). Конечно, в конечном итоге решающим фактором является шебанг. Но расширения файлов действительно занимают свое законное место.Deploy
, хотя это может вызвать проблемы при копировании в файловую систему без учета регистра..sh
расширение, чтобы сценарий открывался в желаемом редакторе. Если вы хотите запускать скрипт при двойном щелчке, дайте ему.command
расширение, и он запустится в Терминале при двойном щелчке.Вам не нужно никакого расширения (или вы можете выбрать произвольное, но
.sh
это полезное соглашение).Вы должны начать свой сценарий с
#!/bin/bash
(эта первая строка понимается системным вызовом execve (2) ), и вы должны сделать свой файл исполняемым с помощьюchmod u+x
. поэтому, если ваш скрипт находится в каком-то файле,$HOME/somedir/somescriptname.sh
вам нужно ввести один разchmod u+x $HOME/somedir/somescriptname.sh
в терминале. См. Chmod (1) для команды и chmod (2) для системного вызова.
Если вы не вводите полный путь к файлу, вам следует поместить этот файл в какой-либо каталог, указанный в вашем
PATH
(см. Environment (7) и execvp (3) ), который вы можете установить постоянно в вашем,~/.bashrc
если ваша оболочка входа в системуbash
)Кстати, вы можете написать свой скрипт на другом языке, например, на Python, запустив его с помощью
#!/usr/bin/python
, или в Ocaml, запустив его с#!/usr/bin/ocaml
...Выполнение вашего скрипта двойным щелчком (на чем? Вы не сказали!) - это проблема среды рабочего стола и может быть специфичной для рабочего стола (может отличаться от Kde, Mate, Gnome, .... или IceWM или RatPoison). Возможно, чтение спецификации EWMH поможет вам лучше понять.
Возможно, создание исполняемого файла сценария с помощью
chmod
может сделать его интерактивным на рабочем столе (по-видимому, Quartz в MacOSX). Но тогда вам, вероятно, следует сделать так, чтобы он давал визуальную обратную связь.А на некоторых компьютерах нет рабочего стола, включая ваш собственный, когда вы получаете доступ к нему удаленно с помощью ssh .
Я не верю, что запускать сценарий оболочки, щелкнув. Вы, вероятно, захотите предоставить аргументы своему сценарию оболочки (и как бы вы это сделали, щелкнув?), И вам следует позаботиться о его выводе. Если вы можете написать сценарий оболочки, вы можете использовать интерактивную оболочку в терминале. Это лучший и наиболее естественный способ использования скрипта. Хорошие интерактивные оболочки (например, zsh или fish или, возможно, недавняя
bash
) имеют восхитительные и настраиваемые средства автозаполнения , и вам не придется много печатать (научитесь пользоваться tabклавишами клавиатуры). Кроме того, скрипты и программы часто являются частями составных команд (конвейеров и т. Д.).PS. Я использую Unix с 1986 года, а Linux с 1993 года. Я никогда не запускал свои собственные программы или сценарии, щелкая. Почему я должен?
источник
chmod +x
вместоchmod u+x
, если нет особой причины ограничить выполнение только владельцем.просто
.sh
.Запускаем скрипт так:
РЕДАКТИРОВАТЬ: Как сказал Анубхава, расширение на самом деле не имеет значения. Но по организационным причинам все же рекомендуется использовать расширения.
источник
.sh
суффикса к исполняемому сценарию, как правило, бесполезно..sh
расширением (и меньше с.bash
расширением), но я не уверен, что это вообще полезно. Если я назову сценарийfoo.sh
и позже решу заново реализовать его на Perl, я могу либо изменить имя (и отредактировать все, что его использует), либо оставить его с вводящим в заблуждение расширением. Если я его назовуfoo
, у меня нет этой проблемы.head -1 script.foo
илиfile script.foo
). Но если все установлено и настроено правильно, в 99% случаев я просто хочу, чтобы команда выполняла то, что она должна делать. Для меня это не оправдывает необходимость знать суффикс.py
или.bash
каждый раз, когда я его запускаю.Я знаю, что это уже довольно давно, но я чувствую, что это добавляет к тому, о чем спрашивал вопрос.
Если вы используете Mac и хотите иметь возможность запускать скрипт, дважды щелкнув его, вам необходимо использовать
.command
расширение. Так же, как и раньше, сделайте файл исполняемым с расширениемchmod -x
.Как было отмечено ранее, на самом деле это не так уж и полезно.
источник
TL; DR - Если пользователь (не обязательно разработчик) скрипта использует графический интерфейс, это зависит от того, какой файловый браузер он использует. Finder MacOS потребует
.sh
расширения для выполнения скрипта. Gnome Nautilus, однако, распознает правильно оформленные скрипты с.sh
расширением или без него .Я знаю, что уже несколько раз говорилось о причинах и против использования расширений в сценариях bash, но не так много, почему или почему не использовать расширения, но у меня есть то, что я считаю хорошим практическим правилом.
Если вы входите и выходите из bash и используете терминал в целом, или разрабатываете инструмент для кого-то еще, кто не использует терминал, добавьте
.sh
расширение в свои сценарии bash. Таким образом, у пользователей этого сценария есть возможность дважды щелкнуть этот файл в браузере файлов графического интерфейса пользователя, чтобы запустить сценарий.Если вы относитесь к типу людей, которые в основном выполняют всю или большую часть своей работы в терминале, не беспокойтесь о том, чтобы добавлять какие-либо расширения в свои сценарии bash. Они бесполезны в терминале, если вы уже настроили свой
~/.bashrc
файл, чтобы визуально отличать скрипты от каталогов.Редактировать:
В браузере файлов Gnome Nautilus с 4 тестовыми файлами (каждый с разрешениями, предоставленными для файла, который должен быть запущен) с глупо простой командой bash, чтобы открыть окно терминала (
gnome-terminal
):Файл без расширения с
#!/bin/bash
в первой строке.Он работал двойным щелчком по файлу.
Файл с
.sh
расширением#!/bin/bash
в первой строке.Он работал двойным щелчком по файлу.
Файл без расширения с НЕТ
#!/bin/bash
в первой строке.Он работал двойным щелчком по файлу ... технически, но графический интерфейс не указывал, что это был сценарий оболочки. Он сказал, что это был просто текстовый файл.
Файл с
.sh
расширением NO#!/bin/bash
в первой строке.Он работал двойным щелчком по файлу.
Однако, как мудро заметил Кейт Томпсон в комментариях к этому ответу, полагаясь на использование
.sh
расширения вместо bash shebang в первой строке файла (#!/bin/bash
), это может вызвать проблемы.Однако, как я помню, когда я ранее использовал MacOS, даже правильно отредактированные (это слово?) Сценарии bash без
.sh
расширения не могли быть запущены из графического интерфейса на MacOS. Я хотел бы, чтобы кто-нибудь поправил меня по этому поводу в комментариях. Если это правда, это докажет, что существует хотя бы один файловый браузер, для которого.sh
расширение имеет значение.источник
.sh
суффиксом и#!/bin/bash
в первой строке, будет ли браузер файлов графического интерфейса использоватьsh
для его вызова (игнорируя shebang)? Если так, это может вызвать некоторые проблемы. (Ответ может быть разным для разных браузеров.)/bin/bash
или/bin/sh
(последнее значение по умолчанию для сценария без shebang). Если/bin/sh
это символическая ссылка на/bin/bash
(что довольно часто), то вы можете определить это, посмотрев на значение$0
. (Кроме того, если bash вызывается по мереsh
его установкиPOSIXLY_CORRECT=y
.)