.sh указав расширение?

Вы в замешательстве. Расширение .sh является лишь подсказкой для людей и абсолютно НЕ влияет на то, как система обрабатывает файл. Unix / Linux не сделал ошибку Windows Secrets.pdf.exe.

Вот что происходит, когда вы набираете foo:

1. Перенаправление для STDIN, STDOUT и STDERR настроено.

2. Оболочка проверяет свою внутреннюю хеш-таблицу, чтобы узнать, знает ли она уже запись $PATH для foo. Если ничего не существует, оболочка ищет каталоги в $PATH, ища файл с именем foo, для которого установлен бит выполнения в его разрешениях для файла. Первые foo побед.

3. Если первые два байта файла foo равны #!, следующая строка - это имя выполняемого интерпретатора. Таким образом, #!/bin/bash вводит скрипт Bash, #!/usr/bin/perl вводит скрипт Perl и т. Д.

4. Если файл начинается с \177ELF, это исполняемый двоичный файл, и запускается ld.so это.

Прочитайте man execve и man ld.so для более подробного объяснения.

Хорошие объяснения здесь уже. Я просто хотел добавить, что идеально Вы не должны использовать расширения файла для исполняемых файлов.

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

Перезапись с нуля обычно считают ошибкой, но для сценариев она может иметь смысл, потому что обычно они не являются настолько большими или имеют большую функциональность. Но давайте предположим, что выполнимо переписать с нуля на некотором другом языке, поддерживая функциональность и params/flags первоначального сценария оболочки.

Пользователи этого сценария не должны знать об этом изменении языка, они будут продолжать выполнять ту же команду, и это продолжит работать.

, Если Ваш сценарий назвали do-something.sh, он может продолжить быть do-something.sh, но теперь он записан в Python (например), и таким образом, Ваша начальная буква подсказка является теперь полностью вводящей в заблуждение.

Суффикс .sh может на самом деле помешать, потому что затем для выполнения его необходимо ввести myscript.sh вместо просто myscript, который не будет работать. Лучше, чтобы просто назвать это "myscript" без суффикса .sh и быстрое использование команды "файла" скажут Вам, если это будет двоичный исполняемый файл (формат ELF на Linux) или сценарий оболочки, или безотносительно другого вида сценария.

QDOS (Быстрая и Грязная Операционная система, позже переименованная к "DOS" IBM после mirosoft, ограбила его и незаконно продала его им), и другие дешевые грабежи CP/M, включая окна, перепутывают все это потому что в тех системах нет такой вещи как выполняют полномочия на файлах. Это привело к бесчисленной безопасности f'ups за прошлые 30-40 лет. На самом деле всего несколько минут назад я просто добрался, несколько макулатурной почты с болваном захватили zip-файл, переименованный к MYPICTURE.JPG.zip :)

Ключевой пункт - это: Расширения не важны в любой подобной Unix системной системе. Имя файла является просто именем и не имеет никакого эффекта на или сценария, или скомпилированный исполняемый файл может работать. Программист может добавить a .sh расширение для обозначения этого файлом является сценарием оболочки, или .py для сценария Python, но в отличие от Windows, любой Unix не заботится об именовании, это заботится о полномочиях.

То, что имеет значение, является исполняемым разрешением, данным в файл. С которым можно свериться

ls -l /path/to/file

Рабочие исполняемые файлы

Для запущения скрипта обычно существует несколько путей.

• Если Ваш текущий каталог совпадает со сценарием, и сценарий имеет исполняемые полномочия, как которые можно выполнить его так ./my_script_name . . текущий каталог средств.
• Если Ваш текущий каталог отличается, и сценарий имеет исполняемые полномочия, можно выполнить его путем определения полного пути: /home/user/bin/my_script_name

(Вышеупомянутые два метода полагаются на наличие исполняемого набора полномочий; является ли файл частью $PATH переменная не важна. Присутствие #! строка также имеет значение; без него он сценарий будет выполняться текущей оболочкой, которую Вы имеете открытый. Если я имею csh сценарий без той строки и попытка выполнить его в ударе с ./my_script.csh , это перестанет работать),

• Если Ваш сценарий расположен в каталоге, который является частью Вашего $PATH переменная, можно выполнить его только путем вызова имени. Можно звонить chmod команда в командной строке только путем введения ее имени, потому что это находится в /bin папка. /bin всегда часть $PATH переменная. В этом исполняемом файле случая полномочия и местоположение вопроса сценария
• Определение интерпретатора как команда и сценарий как аргумент. Тем путем сценарий будет служить входным файлом к интерпретатору.
• Определение источника файла. . filename.sh или source filename.sh заставит сценарий рассматриваться, как будто это был ввод с клавиатуры, т.е. как будто это было введено в командную строку непосредственно. В этом исполняемом файле случая не имеют значения полномочия и местоположение

Примеры

Пример № 1, работающий с интерпретатором, к исполнительным полномочиям

$-> ls -l abc.py                                                               
-rw-rw-r-- 1 xieerqi xieerqi 44 Apr 27 22:39 abc.py
$-> python abc.py                                                              
a
b
c

Пример № 2, работающий с ./ исполняемый набор полномочий, строка хижины установлена.

$-> cat abc.py                                                                 
#!/usr/bin/env python
for letter in 'a' 'b' 'c' :
   print letter
$-> ls -l abc.py
-rwxrwxr-x 1 xieerqi xieerqi 66 Apr 27 23:02 abc.py*
$-> ./abc.py                                                                   
a
b
c

Пример № 3, работающий без набора строки хижины (сбои, потому что удар не может прочитать сценарии Python; никакая строка хижины не принимает текущую оболочку как интерпретатор),

$-> cat abc.py                                                                 
for letter in 'a' 'b' 'c' :
   print letter
$-> ./abc.py                                                                   
./abc.py: 2: ./abc.py: Syntax error: word unexpected (expecting "do")

Пример № 4, запуская скрипт, который имеет исполняемую папку формы набора полномочий, которая является частью $PATH переменная

#  /home/xieerqi/bin is part of my path variable
$-> echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/microchip/xc16/v1.25/bin:/opt/microchip/xc32/v1.40/bin:/opt/microchip/xc8/v1.35/bin:/home/xieerqi/bin:/home/xieerqi/bin/sh

$-> # current directory is /home/xieerqi
$-> pwd
/home/xieerqi
$-> # move the file to ~/bin
$-> mv ~/abc.py ~/bin/abc.py
$-> # now I can run it just by calling the name
$-> abc.py
/home/xieerqi/bin/abc.py: 2: /home/xieerqi/bin/abc.py: Syntax error: word unexpected (expecting "do")
$-> # Syntax error because again, no interpreter specified.                    
$-> # must add #!/usr/bin/env python
$-> vi /home/xieerqi/bin/abc.py          
$-> # after adding the line with vi text editor, we can run
$-> abc.py                                                                     
a
b
c

Пример № 5, удаляя расширение, все еще работает, потому что расширения не имеют значения, но это имеет полномочия и является частью $PATH :

$-> mv ~/bin/abc.py  ~/bin/abc                                                 
$-> abc
a
b
c

Для петляния без расширения, Вы обычно не должны делать многого, просто удостоверьтесь, что у Вас есть (в случае сценариев удара) надлежащая строка хижины в самой первой строке:

#!/bin/bash

затем Вам также нужен tho, делают исполняемый файл файла для системы

chmod 755 yourfilename

, Это совпадает с использованием chmod +x yourfilename, числа легки объясненный.

Это - количество трижды добавленного octals, первое число поддерживает пользователя, второго для группы и третьего для других, больше на котором можно найти здесь .

И если Вы находитесь в том же каталоге, поскольку Ваш сценарий не забывает использовать ./ как это:

./yourfilename