Ключевой момент заключается в следующем: расширения не имеют значения в любой Unix-подобной системной системе. Имя файла является просто именем и не влияет на возможность запуска скрипта или скомпилированного исполняемого файла . Программист может добавить .shрасширение, чтобы указать, что файл является сценарием оболочки или .pyсценарием Python, но в отличие от Windows, любой Unix не заботится о наименовании, он заботится о разрешениях.
Что имеет значение, так это исполняемое разрешение, предоставленное файлу. Который вы можете проверить с
ls -l /path/to/file
Запуск исполняемых файлов
Для запуска скрипта есть несколько способов.
- Если ваш текущий каталог совпадает со сценарием, а сценарий имеет права на выполнение, вы можете запустить его следующим образом
./my_script_name. .Означает текущий каталог.
- Если ваш текущий каталог отличается и скрипт имеет разрешения на выполнение, вы можете запустить его, указав полный путь:
/home/user/bin/my_script_name
(Два вышеупомянутых метода основаны на том, чтобы иметь исполняемый набор разрешений; независимо от того, является ли файл частью $PATHпеременной, значение не имеет. Наличие #!строки также имеет значение; без него скрипт будет выполняться текущей оболочкой, которую вы открыли. Если у меня есть cshскрипт без этой строки, и попробуйте запустить его в bash ./my_script.csh, это не удастся)
- Если ваш скрипт находится в каталоге, который является частью вашей
$PATHпеременной, вы можете запустить его, просто вызвав имя. Вы можете вызвать chmodкоманду в командной строке, просто набрав ее имя, потому что она находится в /binпапке. /binвсегда является частью $PATHпеременной. В этом случае исполняемые права доступа и местоположение скрипта имеют значение
- Указание интерпретатора в качестве команды и сценария в качестве аргумента. Таким образом, скрипт будет служить входным файлом для интерпретатора.
- Поиск файла. С помощью
. filename.shили source filename.shсценарий будет обрабатываться так, как если бы он вводился с клавиатуры, т. Е. Как если бы он был введен непосредственно в командную строку. В этом случае исполняемые права доступа и местоположение не имеют значения
Примеры
Пример # 1, работающий с интерпретатором, для разрешения exec
$-> ls -l abc.py
-rw-rw-r-- 1 xieerqi xieerqi 44 Apr 27 22:39 abc.py
$-> python abc.py
a
b
c
Пример №2, работающий с ./набором разрешений на исполняемый файл, набор строк shebang.
$-> 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, работающий без установки строки shebang (не удается, потому что bash не может читать сценарии python; ни одна строка shebang не принимает текущую оболочку в качестве интерпретатора)
$-> 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
.shв качестве расширения во многих случаях считается плохой практикой: это противоречит тому, как называются другие команды (вы не запускаетеls.elf), оно часто вводит в заблуждение (если выfoo.shначинаете с#!/bin/bash, то при запускеsh foo.shон запускается с другим интерпретатором, чем он создан для ), и если вы переписываетеfoo.shего в программу Python, использование этого расширения означает, что вам нужно выбирать между сохранением вводящего в заблуждение названия и переписыванием каждой вызывающей его программы.