Что это означает в сценариях linux? #!/usr/bin/python -tt - программирование
Подтвердить что ты не робот

Что это означает в сценариях linux? #!/usr/bin/python -tt

Я знаю, что в начале .sh bash скрипты

#!/bin/bash

который указывает на исполняемый файл команды.

Но во время просмотра Google Python Class http://www.youtube.com/watch?v=tKTZoB2Vjuk я заметил, что для python они используют

#!/usr/bin/python -tt

. Серфинг в Интернете Я также нашел такие стили этой нотации:

#!/usr/local/bin/python

и даже

#!/usr/bin/env python

.

Итак, я новичок в Python, и я обычный пользователь Linux, и у меня есть несколько вопросов об этой "волшебной" линии:

  • Прежде всего, какова правильная форма этой линии? и почему?
  • Что означает ключ -tt в #!/usr/bin/python -tt?
  • Какая программа анализирует эту строку в Linux?
  • Какой синтаксис этой строки для любого script?
  • Почему эта строка так необходима, если в каждом файле есть расширение?
  • А как насчет того, что в каждом интерпретаторе компьютера для каких-то скриптов будет храниться в другом месте, чем в другом? И script не может быть запущен.

Мне это очень интересно. Что это за линия? Почему эта линия? Как написать эту строку? Почему так?...

4b9b3361

Ответ 1

Вопрос №1) Линия называется shebang, и нет никакой правильной формы, которая работает повсеместно. например.

#!python
#!/usr/bin/python
#!/usr/local/bin/python
#!/usr/bin/python -t

- все допустимые/приемлемые формы, но могут не работать во всех системах:

#!python будет работать только в том случае, если исполняемый файл python находится где-то в вашей оболочке PATH

#!/usr/bin/python работает только в том случае, если бинар python фактически находится в /usr/bin

#!/usr/local/bin/python также работает только в том случае, если python находится в /usr/local/bin

Вопрос № 2)

#!/usr/bin/python -tt передает параметр -tt на python, как если бы вы сделали:

$ python -t somescript.py

в командной строке оболочки. Вы можете передать аргументы командной строки в интерпретатор на линии shebang.

Вопрос № 3)

Строка интерпретируется ядром ОС и оболочкой, которую вы сейчас используете. Материал после #! просто сообщает ОС, какая программа должна быть запущена, чтобы "выполнить" оставшуюся часть script.

Вопрос № 4)

Синтаксис script зависит от языка, который вы используете. Например. оболочка PHP script должна иметь вид

#!/usr/bin/php
<?php
  ... php code here ...

A #!/usr/bin/perl perl script должен использовать синтаксис Perl и т.д. Если вы поместите PHP-код в Perl-shebang, у вас будет только Perl-скрипт с script с синтаксическими ошибками, так как PHP-код НЕ Perl-код

Вопрос № 5)

Shebangs предназначены для Unix-систем, где расширения файлов никогда не использовались для идентификации типов файлов в ОС. Файл .c понимался как исходный код языка C, но это просто соглашение. Вы можете поместить Bash shell script в файл .c, сделать его исполняемым, а с помощью #!/bin/bash shebang он будет выполняться как Bash script.

Определение типов исполняемых файлов с помощью расширения файла больше относится к Windows.

Вопрос № 6)

Это возвращает материал, о котором идет речь # 1 - если shebang утверждает, что интерпретатор находится на каком-то ДРУГОЙ путь, чем там, где он есть, этот конкретный script не может быть выполнен до тех пор, пока shebang не будет зафиксирован, или переводчик не будет перемещен, Шебанги очень удобны, но не безошибочны.

К счастью, большинство интерпретаторов установлены в довольно стандартных местах в наши дни, поэтому было бы несколько необычно найти (скажем) Perl, установленный в /some/wonky/weird/path вместо /usr/bin

Ответ 2

Из man-страницы:

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

  • Правильная форма строки - это та, которую вы хотите использовать.
  • Это интерпретатор, который читает эту строку, называемую shebang. Если вы пишите python script с первой строкой как "#!/Usr/bin/python" и вызывают его с помощью bash, это интерпретатор /bin/sh, который читает первую строку и запускает правильный интерпретатор.
  • Это shebang. Синтаксис функции состоит из последовательности символов #!, То есть знака числа и символа восклицательного знака
  • Расширения файлов в Linux вообще не актуальны. У вас может быть python script, у которого нет расширения .py.

Например,

[email protected] ~ $ cat a 
print "Hello World" 
[email protected] ~ $ python2 a 
Hello World 
[email protected] ~ $

Даже shebangs необходимы, только если вы хотите запустить script с помощью $./script, поскольку в этом случае вы не указали интерпретатор, который хотите использовать.

Ответ 3

  • #!/usr/bin/env python
  • выдавать ошибки о несогласованном использовании вкладок
  • Kernel
  • #!/path_to_the_interpreter или /usr/bin/env
  • * nix не проверяет extensinon вообще (за исключением того, что DE может это сделать)
  • Вот почему вы должны использовать #!/usr/bin/env

Дополнительная информация на wiki

Ответ 4

Различные пути - это место, где установлен интерпретатор python. Различные варианты Linux устанавливают его в разных местах.

Linux не заботится о расширении своей вещи Windows.

Сегмент bash использует строку для вызова правильного интерпретатора для script вашего запуска.

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

Я бы предложил получить книгу по Linux/Unix и изучить основы файловой системы. Это очень помогает.

Ответ 5

Это называется shebang. Он сообщает системе, что он должен передать файл в качестве аргумента указанной программе, а не пытаться выполнить ее сам по себе.

Прежде всего, какова правильная форма этой линии? и почему?

Правильный путь - там, где установлен ваш интерпретатор python. Аргументы (-tt) будут зависеть от того, что вы хотите. Некоторые люди настаивают на #!/usr/bin/env, если интерпретатор оказывается в элементе.

Что означает ключ -tt в #!/usr/bin/python -tt?

Я не использую python, поэтому кому-то придется ответить на этот вопрос.

Когда я запускаю любой script в Linux (не точный Python script), какая программа анализирует и использует эту строку? Я считаю, что это не bash, потому что даже для bash скриптов эта строка нужна.

Я слышал (и довольно уверен) это ядро. Даже если это было bash, для строки bash нужна строка, она должна быть script, она должна интерпретироваться вместо перехода к другой программе. /usr/bin/env - это команда, которая ищет PATH для указанного аргумента и передает script через найденную программу.

Какой синтаксис этой строки для любого script? И какое имя интерпретатора это анализирует?

Синтаксис такой же, как в командной строке, #!command arguments, но command должен быть абсолютным путем, PATH не выполняется поиск.

Почему эта строка настолько необходима, если в каждом файле есть расширение?

Расширения ничего не означают в * nix. Я мог бы назвать bash script script.pl, script.exe или даже script без расширения. Если script имеет правую строку shebang, он проходит через правый интерпретатор, иначе ядро ​​пытается выполнить его как исполняемый файл и терпит неудачу. Система не знает о расширениях. Это соглашение для пользователей, не более того.

А как насчет того, что в каждом интерпретаторе компьютера для каких-то скриптов будет храниться в другом месте, чем в другом? И script не может быть запущен.

Если я правильно понимаю это, вы говорите, что разные системы/дистрибутивы поддерживают интерпретаторы в разных местах (например, /usr/bin/python и /usr/local/bin/python) и спрашивают, как система знает, что использовать?
Ответ заключается в том, что он использует тот, который находится на абсолютном пути, который вы ему дали. На самом деле это небольшая проблема с исполняемыми скриптами, и причина, по которой /usr/bin/env вступила в моду. Как я уже сказал, env ищет PATH для правильного интерпретатора, поэтому, если ваша система имеет /usr/bin/env, вы настроены, вам не нужно искать или гарантировать местоположение интерпретатора.