Навіщо використовувати методи модуля ос на Python замість виконання команд оболонки безпосередньо?

Я намагаюся зрозуміти, в чому полягає мотивація використання бібліотечних функцій 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")

Це можна легко використовувати для запуску будь-якого довільного коду за допомогою вводу: NASTY COMMAND;#для створення можливого:

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

Є багато таких команд, які можуть піддавати вашій системі небезпеку.

З простої причини - коли ви викликаєте функцію оболонки, вона створює під-оболонку, яка знищується після існування вашої команди, тому, якщо ви змінюєте каталог в оболонці - це не впливає на ваше оточення в Python.

Крім того, створення підрозділу вимагає багато часу, тому використання команд ОС безпосередньо вплине на вашу ефективність

EDIT

У мене були запущені кілька тестів на терміни:

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 з тієї ж причини: вона робить необхідні системні виклики себе замість нерестування тисячі оболонок.