Зачем использовать методы модуля Python os вместо непосредственного выполнения команд оболочки?

Я пытаюсь понять, что является мотивацией использования библиотечных функций Python для выполнения специфических для ОС задач, таких как создание файлов / каталогов, изменение атрибутов файлов и т. Д., Вместо простого выполнения этих команд с помощью os.system()или subprocess.call()?

Например, почему я хотел бы использовать os.chmodвместо того, чтобы делать os.system("chmod...")?

Я понимаю, что более «питонно» использовать как можно больше доступных библиотечных методов Python вместо того, чтобы просто выполнять команды оболочки напрямую. Но есть ли какая-либо другая мотивация для этого с функциональной точки зрения?

Я говорю только о выполнении простых однострочных команд оболочки здесь. Когда нам нужно больше контроля над выполнением задачи, я понимаю, что с помощьюsubprocess модуля имеет больше смысла, например.

1. Это быстрее , os.systemи subprocess.callсоздавать новые процессы, которые не нужны для чего-то такого простого. Фактически, os.systemи subprocess.callс shellаргументом обычно создают как минимум два новых процесса: первый - это оболочка, а второй - команда, которую вы запускаете (если это не встроенная оболочка, как test).

2. Некоторые команды бесполезны в отдельном процессе . Например, если вы запустите os.spawn("cd dir/"), он изменит текущий рабочий каталог дочернего процесса, но не процесса Python. Вы должны использовать os.chdirдля этого.

3. Вам не нужно беспокоиться о специальных символах, интерпретируемых оболочкой. os.chmod(path, mode)будет работать независимо от того, какое имя файла, а os.spawn("chmod 777 " + path)ужасно потерпит неудачу, если имя файла будет чем-то вроде ; rm -rf ~. (Обратите внимание, что вы можете обойти это, если вы используете subprocess.callбез shellаргумента.)

4. Вам не нужно беспокоиться об именах файлов, начинающихся с тире . os.chmod("--quiet", mode)изменит права доступа к названному файлу --quiet, но os.spawn("chmod 777 --quiet")потерпит неудачу, так как --quietинтерпретируется как аргумент. Это верно даже для subprocess.call(["chmod", "777", "--quiet"]).

5. У вас меньше проблем с кроссплатформенностью и кросс-оболочкой, так как стандартная библиотека Python должна решить эту проблему для вас. У вашей системы есть chmodкоманда? Это установлено? Поддерживает ли он параметры, которые вы ожидаете поддерживать? osМодуль будет пытаться быть кросс-платформенным , как это возможно и документов , когда , что это не возможно.

6. Если команда, которую вы запускаете, имеет вывод, который вас волнует, вам нужно проанализировать его, что сложнее, чем кажется, поскольку вы можете забыть о угловых случаях (имена файлов с пробелами, табуляцией и символами новой строки в них), даже если вы не волнует переносимость

Это безопаснее. Чтобы дать вам представление, вот пример сценария

import os
file = raw_input("Please enter a file: ")
os.system("chmod 777 " + file)

Если вход от пользователя был test; rm -rf ~ таким, то удалял бы домашний каталог.

Вот почему безопаснее использовать встроенную функцию.

Следовательно, почему вы должны использовать подпроцесс вместо системы тоже.

Есть четыре веских аргумента в пользу предпочтения более специфических методов Python в osмодуле, чем при использовании os.systemили subprocessмодуле при выполнении команды:

• Избыточность - порождение другого процесса является избыточным и тратит время и ресурсы.
• Переносимость - многие из методов в osмодуле доступны на нескольких платформах, в то время как многие команды оболочки зависят от ОС.
• Понимание результатов - порождение процесса для выполнения произвольных команд вынуждает вас анализировать результаты из вывода и понимать, если и почему команда сделала что-то не так.
• Безопасность - процесс может потенциально выполнить любую команду, которую ему дают. Это слабый дизайн, и его можно избежать, используя специальные методы в osмодуле.

Избыточность (см. Избыточный код ):

Вы фактически выполняете избыточного «посредника» на пути к возможным системным вызовам (chmod в вашем примере). Этот средний человек - это новый процесс или суб-оболочка.

От os.system:

Выполнить команду (строку) в подоболочке ...

И subprocess это просто модуль для порождения новых процессов.

Вы можете делать то, что вам нужно, не вызывая эти процессы.

Переносимость (см. Переносимость исходного кода ):

Целью osмодуля является предоставление общих служб операционной системы, и его описание начинается с:

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

Вы можете использовать os.listdirкак на Windows, так и на Unix. Попытка использовать os.system/ subprocessдля этой функции заставит вас выполнить два вызова (для ls/ dir) и проверить, в какой операционной системе вы работаете. Это не так переносимо и позже приведет к еще большему разочарованию (см. Обработка вывода ).

Понимание результатов команды:

Предположим, вы хотите перечислить файлы в каталоге.

Если вы используете os.system("ls")/subprocess.call(['ls']) , вы можете получить только выходные данные процесса, которые в основном представляют собой большую строку с именами файлов.

Как вы можете отличить файл с пробелом в имени от двух файлов?

Что если у вас нет разрешения перечислять файлы?

Как вы должны отобразить данные на объекты Python?

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

Это пример того , чтобы следовать не повторяйте себя принцип (часто обозначаемый как «DRY») по не повторять реализацию , которая уже существует и свободно доступны для вас.

Безопасность:

os.systemи subprocessмощные. Это хорошо, когда тебе нужна эта сила, но это опасно, когда тебе это не нужно. Когда вы используете os.listdir, вы знаете, что он не может делать ничего другого, кроме списка файлов или выдавать ошибку. Когда вы используете os.systemилиsubprocess для достижения того же поведения, вы можете в конечном итоге сделать то, что вы не хотели делать.

Безопасность впрыска (см. Примеры инъекций в оболочку ) :

Если вы используете ввод от пользователя в качестве новой команды, вы в основном дали ему оболочку. Это очень похоже на SQL-инъекцию, предоставляющую пользователю оболочку в БД.

Примером может служить команда вида:

# ... read some user input
os.system(user_input + " some continutation")

Это может быть легко использовано для запуска любого произвольного кода, используя input: NASTY COMMAND;#для создания возможного:

os.system("NASTY COMMAND; # some continuation")

Есть много таких команд, которые могут поставить вашу систему под угрозу.

По простой причине - когда вы вызываете функцию оболочки, она создает вложенную оболочку, которая уничтожается после того, как ваша команда существует, поэтому, если вы измените каталог в оболочке - это не повлияет на вашу среду в Python.

Кроме того, создание суб-оболочки занимает много времени, поэтому использование команд ОС напрямую повлияет на вашу производительность.

РЕДАКТИРОВАТЬ

У меня было несколько временных тестов:

In [379]: %timeit os.chmod('Documents/recipes.txt', 0755)
10000 loops, best of 3: 215 us per loop

In [380]: %timeit os.system('chmod 0755 Documents/recipes.txt')
100 loops, best of 3: 2.47 ms per loop

In [382]: %timeit call(['chmod', '0755', 'Documents/recipes.txt'])
100 loops, best of 3: 2.93 ms per loop

Внутренняя функция работает более чем в 10 раз быстрее

EDIT2

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

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

Это гораздо эффективнее. «Оболочка» - это просто еще один бинарный файл ОС, который содержит множество системных вызовов. Зачем тратить время на создание всего процесса оболочки только для одного системного вызова?

Ситуация еще хуже, когда вы используете os.systemчто-то, что не является встроенной оболочкой. Вы запускаете процесс оболочки, который, в свою очередь, запускает исполняемый файл, который затем (на расстоянии двух процессов) выполняет системный вызов. По крайней мереsubprocess , устранена необходимость в промежуточном процессе оболочки.

Это не относится к Python, это. systemdЭто такое улучшение времени запуска Linux по той же причине: оно делает необходимые системные вызовы сам, а не порождает тысячу оболочек.