Python - Когда Это хорошо для Использования os.system () для выдачи общих команд Linux

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

Кажется, ваш вопрос состоит из двух частей. Вы упомянули о вызове таких команд, как «xterm», «rm -rf» и «cd».

Боковое примечание: вы не можете вызывать cd во вспомогательной оболочке. Бьюсь об заклад, это был вопрос с подвохом ...

Что касается других вещей командного уровня, которые вы, возможно, захотите сделать, например "rm -rf SOMETHING", то уже существует эквивалент для Python. Это ответ на первую часть вашего вопроса. Но я подозреваю, что вы действительно спрашиваете о второй части.

Вторую часть вашего вопроса можно перефразировать как «следует ли мне использовать system () или что-то вроде модуля подпроцесса?».

У меня есть простой ответ: просто скажите НЕТ использованию "system ()", за исключением прототипирования.

Это нормально для проверки того, что что-то работает, или для этого «быстрого и грязного» сценария, но слишком много проблем с os.system ():

1. Он создает для вас оболочку - отлично, если вам нужно one
2. Он расширяет подстановочные знаки для вас - отлично, если у вас их нет
3. Он обрабатывает перенаправление - отлично, если вы этого хотите
4. Он выгружает вывод в stderr / stdout и по умолчанию читает из stdin
5. Он пытается понять цитирование, но это не очень хорошо (попробуйте 'Cmd ">" Ofile')
6. Что касается пункта 5, он не всегда проверяет границы аргументов (т.е. аргументы с пробелами в них могут облажаться)

Просто скажи нет "system ()"!

Я бы посоветовал вам использовать os.system только для тех вещей, для которых еще нет эквивалентов в модуле os . Зачем усложнять себе жизнь?

Вызов os.system в Python начинает «неодобрительно относиться». «Новой» заменой будет subprocess.call или subprocess.Popen в модуле subprocess. Проверьте документацию на подпроцесс

. Еще одна приятная вещь в подпроцессе - это то, что вы можете читать stdout и stderr в переменных и обрабатывать их без перенаправления на другой файл (ы).

Как уже было сказано выше, для большинства вещей существуют модули. Если вы не пытаетесь склеить множество других команд, я бы остановился на вещах, включенных в библиотеку. Если вы копируете файлы, используйте shutil, работая с архивами, у вас есть такие модули, как tarfile / zipfile и так далее.

Удачи.

Одна из проблем с system() заключается в том, что она подразумевает знание синтаксиса и языка оболочки для разбора и выполнения вашей командной строки. Это создает потенциал для ошибки, когда вы не проверили ввод должным образом, и оболочка может интерпретировать что-то вроде подстановки переменных или определения начала или конца аргумента таким образом, которого вы не ожидаете. Кроме того, оболочка другой ОС может иметь отличный от вашей синтаксис, включая очень тонкие расхождения, которые вы не сразу заметите. По этим причинам я предпочитаю использовать execve() вместо system() - вы можете передавать токены argv напрямую и не беспокоиться о том, что что-то в середине (неправильно) разберет ваш ввод.

Другая проблема с system() (это также относится к использованию execve()) заключается в том, что когда вы пишете этот код, вы говорите: "Ищите эту программу и передайте ей эти args". При этом делается несколько предположений, которые могут привести к ошибкам. Первое - что программа существует и может быть найдена в $PATH. Возможно, на какой-то системе это не так. Во-вторых, возможно, на какой-то системе или даже в будущей версии вашей собственной ОС она будет поддерживать другой набор опций. В этом смысле, я бы избегал делать это, если вы не уверены, что система, на которой вы будете работать, будет иметь эту программу. (Например, возможно, вы изначально поместили вызывающую программу в систему, или способ ее вызова предписан чем-то вроде POSIX.)

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

Это лишь несколько причин избегать system(). Наверняка есть и другие.

Ответ Дарина - хорошее начало.

Кроме того, все зависит от того, насколько портативным вы планируете стать. Если ваша программа будет работать только на достаточно «стандартном» и «современном» Linux, то у вас нет причин заново изобретать колесо; если вы попытаетесь переписать make или xterm , они отправят за вас людей в белых халатах. Если это работает и у вас нет проблем с платформой, выбейте себя и просто используйте Python в качестве клея!

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