Фактическое значение 'shell = True' в подпроцессе

Я называю разные процессы с subprocessмодулем. Однако у меня есть вопрос.

В следующих кодах:

callProcess = subprocess.Popen(['ls', '-l'], shell=True)

и

callProcess = subprocess.Popen(['ls', '-l']) # without shell

Оба работают. Прочитав документы, я узнал, что это shell=Trueозначает выполнение кода через оболочку. Таким образом, это означает, что в отсутствие процесс запускается напрямую.

Итак, что я предпочитаю для своего случая - мне нужно запустить процесс и получить его вывод. Какую выгоду я получаю от вызова изнутри или снаружи.

Преимущество отказа от вызова через оболочку состоит в том, что вы не вызываете «загадочную программу». В POSIX переменная среды SHELLопределяет, какой двоичный файл вызывается как «оболочка». В Windows нет потомка оболочки Bourne, только cmd.exe.

Таким образом, вызов оболочки вызывает программу по выбору пользователя и зависит от платформы. Вообще говоря, избегайте вызовов через оболочку.

Вызов через оболочку позволяет расширять переменные среды и файловые глобусы в соответствии с обычным механизмом оболочки. В системах POSIX оболочка расширяет файловые глобусы до списка файлов. В операционной системе Windows, файл - Глоб (например, «*. *») Не расширяется за счет оболочки, так или иначе (но переменные окружения в командной строке будут расширены cmd.exe).

Если вы считаете, что вам нужны расширения переменных среды и глобусы файлов, изучите ILSатаки 1992-го года на сетевые службы, которые выполняли вызовы подпрограмм через оболочку. Примеры включают в себя различные sendmailбэкдоры с участием ILS.

В заключение, используйте shell=False.

>>> import subprocess
>>> subprocess.call('echo $HOME')
Traceback (most recent call last):
...
OSError: [Errno 2] No such file or directory
>>>
>>> subprocess.call('echo $HOME', shell=True)
/user/khong
0

Установка аргумента оболочки в истинное значение заставляет подпроцесс порождать промежуточный процесс оболочки и сообщать ему о запуске команды. Другими словами, использование промежуточной оболочки означает, что переменные, шаблоны глобусов и другие специальные функции оболочки в командной строке обрабатываются до запуска команды. Здесь, в примере, $ HOME был обработан перед командой echo. На самом деле, это случай команды с расширением оболочки, тогда как команда ls -l рассматривается как простая команда.

источник: модуль подпроцесса

Пример, где все может пойти не так с Shell = True, показан здесь

>>> from subprocess import call
>>> filename = input("What file would you like to display?\n")
What file would you like to display?
non_existent; rm -rf / # THIS WILL DELETE EVERYTHING IN ROOT PARTITION!!!
>>> call("cat " + filename, shell=True) # Uh-oh. This will end badly...

Проверьте документ здесь: subprocess.call ()

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

shell=Trueиногда удобно использовать определенные функции оболочки, такие как разделение слов или расширение параметров. Однако, если такая функция требуется, используйте другие модули (например, os.path.expandvars()для расширения параметров или shlexдля разделения слов). Это означает больше работы, но позволяет избежать других проблем.

Короче говоря: избегайте во что shell=Trueбы то ни стало.

Другие ответы здесь адекватно объясняют предостережения безопасности, которые также упоминаются в subprocessдокументации. Но в дополнение к этому, издержки запуска оболочки для запуска программы, которую вы хотите запустить, часто не нужны и, безусловно, глупы в ситуациях, когда вы фактически не используете какую-либо функциональность оболочки. Более того, дополнительная скрытая сложность должна пугать вас, особенно если вы не очень хорошо знакомы с оболочкой или предоставляемыми ей службами.

Там, где взаимодействия с оболочкой нетривиальны, теперь вам требуется, чтобы читатель и сопровождающий сценария Python (который может быть вашим будущим я или не мог) понимал как Python, так и сценарий оболочки. Помните девиз Python «явное лучше, чем неявное»; даже если код Python будет несколько более сложным, чем эквивалентный (и часто очень краткий) сценарий оболочки, вам может быть лучше удалить оболочку и заменить функциональность собственными конструкциями Python. Минимизация работы, выполняемой во внешнем процессе, и сохранение контроля в собственном коде, насколько это возможно, часто является хорошей идеей просто потому, что она улучшает видимость и снижает риски нежелательных или нежелательных побочных эффектов.

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

В тривиальном случае, чтобы избежать shell=True, просто замените

subprocess.Popen("command -with -options 'like this' and\\ an\\ argument", shell=True)

с участием

subprocess.Popen(['command', '-with','-options', 'like this', 'and an argument'])

Обратите внимание, как первый аргумент представляет собой список строк для передачи execvp(), и как в кавычках строки и метасимволы оболочки с обратной косой чертой обычно не нужны (или полезны, или корректны). Может быть, смотрите также Когда обернуть кавычки вокруг переменной оболочки?

Кроме того, вы очень часто хотите избежать, Popenесли один из более простых упаковщиков в subprocessпакете делает то, что вы хотите. Если у вас достаточно недавний Python, вы, вероятно, должны использовать subprocess.run.

• При check=Trueэтом произойдет сбой, если команда, которую вы запустили, не удалась.
• С stdout=subprocess.PIPEего помощью будет получен вывод команды.
• Несколько непонятно, с universal_newlines=Trueэтим он будет декодировать вывод в правильную строку Unicode ( bytesиначе это просто в системной кодировке на Python 3).

Если нет, то для многих задач вы хотите check_outputполучить выходные данные команды, одновременно проверяя, успешно check_callли она выполнена или нет ли выходных данных для сбора.

В заключение я приведу цитату Дэвида Корна: «Легче написать переносную оболочку, чем сценарий переносимой оболочки». Даже subprocess.run('echo "$HOME"', shell=True)не переносится на Windows.