Pourquoi utiliser Python module os méthodes au lieu d'exécution de l'interpréteur de commandes directement?

J'essaie de comprendre quelle est la motivation derrière à l'aide de Python à la bibliothèque de fonctions pour l'exécution d'OS tâches spécifiques telles que la création de fichiers/répertoires, modification des attributs de fichier, etc. au lieu de simplement l'exécution de ces commandes via os.system() ou subprocess.call()?

Par exemple, pourquoi voudrais-je utiliser os.chmod au lieu de faire os.system("chmod...")?

Je comprends que c'est plus "pythonic" utiliser Python est disponible à la bibliothèque de méthodes, autant que possible, au lieu de simplement exécution de l'interpréteur de commandes directement. Mais, est-il un autre motivation derrière de faire cela à partir d'une fonctionnalité de point de vue?

Je ne parle que de l'exécution d'un simple interpréteur de ligne de commandes ici. Lorsque nous avons besoin de plus de contrôle sur l'exécution de la tâche, je comprends que l'utilisation de subprocess module a plus de sens, par exemple.

  • En gros, vous frappez le clou sur la tête. Au niveau de l'OS tâches que vous consultez sont assez communs qu'ils ne le méritent leur propre fonction au lieu d'être simplement relégués à être appelé via le système d'exploitation.système.
  • BTW, avez-vous essayer de temps en temps d'exécution du système d'exploitation.chmod vs os.system("chmod..."). Je hasarder une conjecture qu'il répondra à une partie de votre question.
  • Pourquoi avoir print quand vous pourriez os.system("echo Hello world!") ?
  • Pour la même raison, vous devez utiliser os.path pour gérer les chemins d'accès au lieu de saisir manuellement les manipuler: il fonctionne sur tous les OS dans lequel il s'exécute.
  • "Exécution de l'interpréteur de commandes directement" est, en réalité, moins directe. Le shell n'est pas une interface de bas niveau pour le système, et os.chmod ne va pas à appeler les chmod programme de la shell. À l'aide de os.system('chmod ...') lance un shell pour interpréter une chaîne d'appeler un autre fichier exécutable pour faire un appel à la C chmod fonction, tandis que os.chmod(...) va beaucoup plus directement à la C chmod.
  • strictement parlant, il n'est pas nécessairement aller à C de chmod, mais plutôt de faire un chmod syscall. Dans Disponible de cas, il n'est probablement pas ré-écrire le local syscall convention, mais plutôt à réutiliser la bibliothèque C du syscall l'application de la convention, mais d'autres implémentations peuvent éventuellement décider autrement.

InformationsquelleAutor Koderok | 2015-02-17
  1. 325

    1. C'est plus rapide, os.system et subprocess.call créer de nouveaux processus qui est inutile pour quelque chose de simple. En fait, os.system et subprocess.call avec le shell argument généralement de créer au moins deux nouveaux processus: le premier étant la coquille, et la seconde étant la commande que vous utilisez (si ce n'est pas un shell intégré comme test).

    2. Certaines commandes sont inutile dans un processus séparé. Par exemple, si vous exécutez os.spawn("cd dir/"), il va changer le répertoire de travail courant du processus enfant, mais pas du Python processus. Vous avez besoin d'utiliser os.chdir pour que.

    3. Vous n'avez pas à vous soucier de spécial caractères interprétés par le shell. os.chmod(path, mode) fonctionne, peu importe ce que le nom de fichier, alors que les os.spawn("chmod 777 " + path) échouera horriblement si le nom de fichier est quelque chose comme ; rm -rf ~. (Notez que vous pouvez contourner ce problème si vous utilisez subprocess.call sans shell argument.)

    4. Vous n'avez pas à vous soucier de les noms de fichiers qui commencent par un tiret. os.chmod("--quiet", mode) va changer les permissions du fichier nommé --quiet, mais os.spawn("chmod 777 --quiet") échouera, car --quiet est interprété comme un argument. Cela est vrai même pour subprocess.call(["chmod", "777", "--quiet"]).

    5. Vous avez moins de de la croix-plate-forme et de la croix-shell préoccupations, comme Python standard library est supposée traiter avec que pour vous. Est-ce que votre système de chmod commande? Est-il installé? Prend-il en charge les paramètres que vous attendez de soutien? Le os module va essayer d'être aussi multi-plateforme que possible et de documents lors qu'il n'est pas possible.

    6. Si la commande que vous êtes en cours d'exécution a sortie que vous vous souciez, vous devez l'analyser, ce qui est plus compliqué que ça, comme vous pouvez oublier le coin des cas (les noms de fichiers avec des espaces, les tabulations et les retours à la ligne en mer), même lorsque vous ne se soucient pas de la portabilité.

    • Pour ajouter à la "cross-platform", le point, le listage d'un répertoire est "ls" sur linux, "dir" sur windows. L'obtention du contenu d'un répertoire est un très commun de faible niveau de la tâche.
    • est relatif, ls ou dir sont assez haut niveau à certains types de développeurs, tout comme bash ou cmd ou ksh ou quel que soit le shell que vous préférez sont.
    • Je n'ai jamais pensé de cette façon. Pour moi, "appel direct à votre système d'exploitation noyau de l'API" a été très faible niveau. Je suis en supposant qu'il existe un point de vue différent sur ce qui est faussé compagnie à moi parce que je suis (évidemment) de l'approcher avec mes propres préjugés.
    • droit, et ls est de niveau plus élevé que cela, puisqu'il n'est pas un appel direct à votre système d'exploitation noyau de l'API. C'est un (petit) de l'application.
    • J'ai appelé "l'obtention du contenu d'un répertoire de" bas niveau. Je ne pense pas ls ou dir mais opendir()/readdir() (linux api) ou FindFirstFile()/FindNextFile() (api windows) ou File.listFiles (API java) ou Directory.GetFiles() (C#). Tous ces éléments sont étroitement liés à un appel direct à l'OS. Certains peuvent être aussi simple que de pousser un numéro dans un registre et en appelant int 13h pour déclencher en mode noyau.
    • ah, ISWYM. J'ai combiné de votre remarque sur la "liste d'un répertoire" avec votre remarque sur "obtenir le contenu d'un répertoire", en supposant que vous vouliez parler de la même chose dans les deux cas. Mais maintenant je me rends compte vraisemblablement partie du point de ce commentaire était de distinguer les deux, pas d'amalgame entre eux 🙂
    • Franchement, je mettrais le de la croix-plate-forme préoccupation sur le dessus: This module provides a portable way... docs.python.org/2/library/os.html

    InformationsquelleAutor Flimm
  2. 133

    C'est plus sûr. Pour vous donner une idée, voici un exemple de script

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

    Si l'entrée de l'utilisateur a été test; rm -rf ~ ce serait alors supprimer le répertoire d'accueil.

    C'est pourquoi il est plus sûr d'utiliser le construit en fonction.

    C'est pourquoi vous devriez utiliser des sous-processus au lieu de système de trop.

    • Ou une autre façon de voir les choses, ce qui est plus facile à obtenir le droit, écrit en Python programmes ou de l'écriture des programmes Python qui d'écrire des scripts shell? 🙂
    • un de mes collègues a été étonné de voir qu'un petit script Python, je l'ai aidé à écrire travaillé 20 (!) fois plus rapide tan script shell. J'ai expliqué que la redirection de la sortie peut avoir l'air sexy - mais elle implique l'ouverture et de la fermeture du fichier à chaque itération. Mais certaines aiment faire des choses à la dure -:)
    • c'est une question piège -- vous ne savez pas jusqu'à exécution! 🙂
    InformationsquelleAutor iProgram
  3. 60

    Il y a quatre forts cas pour préférant Python de plus de méthodes spécifiques dans le os module sur l'utilisation de os.système ou la sous-processus module lors de l'exécution d'une commande:

    • Redondance le frai est un autre processus redondants et des pertes de temps et de ressources.
    • Portabilité - de Nombreuses méthodes dans le os module sont disponibles dans de multiples plates-formes, tandis que de nombreuses commandes shell sont spécifiques aux systèmes d'exploitation.
    • La compréhension des résultats Frayant un processus à exécuter des commandes arbitraires vous oblige à analyser les résultats à partir de la sortie et de comprendre si et pourquoi une commande a fait quelque chose de mal.
    • Sécurité - Un processus qui peut, potentiellement, d'exécuter n'importe quelle commande il est donné. C'est une mauvaise conception, et il peut être évité en utilisant des méthodes spécifiques de l' os module.

    Redondance (voir code redondant):

    Vous êtes réellement l'exécution d'une redondant "middle-man" sur votre chemin à l'éventuel système d'appels (chmod dans votre exemple). Cet homme du milieu est un nouveau processus ou d'un sous-shell.

    De os.système:

    Exécuter la commande (une chaîne de caractères) dans un shell interne est exécuté ...

    Et sous-processus est tout simplement un module de frayer de nouveaux processus.

    Vous pouvez faire ce que vous avez besoin sans frai de ces processus.

    Portabilité (voir code source de la portabilité):

    La os module vise à fournir générique de système d'exploitation de services et c'est la description commence par:

    Ce module fournit un portable manière d'utiliser le système d'exploitation dépendant de la fonctionnalité.

    Vous pouvez utiliser os.listdir à la fois sur windows et unix. Essayez d'utiliser os.system /subprocess pour que cette fonctionnalité va vous forcer à maintenir deux appels (pour ls /dir) et de vérifier quel système d'exploitation que vous utilisez. Ce n'est pas aussi portable et sera causer encore plus de frustration plus tard (voir gestion de Sortie).

    La compréhension de la commande de résultats:

    Supposons que vous voulez la liste des fichiers dans un répertoire.

    Si vous utilisez os.system("ls") /subprocess.call(['ls']), vous pouvez seulement obtenir le processus de sortie de retour, qui est fondamentalement une grosse chaîne avec les noms de fichier.

    Comment pouvez-vous dire à un fichier avec un espace dans son nom de deux fichiers?

    Que faire si vous n'avez pas l'autorisation d'afficher la liste des fichiers?

    Comment mapper les données d'objets python?

    Ce sont seulement sur le haut de ma tête, et bien qu'il existe des solutions à ces problèmes - pourquoi résoudre encore un problème qui a été résolu pour vous?

    Ceci est un exemple de la suite de la Ne Vous Répétez pas principe (Souvent désigné comme la "SEC") par pas répétition d'une mise en œuvre qui existe déjà et qui est disponible gratuitement pour vous.

    De sécurité:

    os.system et subprocess sont puissants. C'est bon lorsque vous avez besoin de cette puissance, mais c'est dangereux quand vous n'en avez pas. Lorsque vous utilisez os.listdir, vous savoir elle ne peut rien faire d'autre, puis d'autres de la liste de fichiers ou de générer une erreur. Lorsque vous utilisez os.system ou subprocess pour obtenir le même comportement, vous pouvez éventuellement finir par faire quelque chose que vous ne voulais pas faire.

    D'Injection de Sécurité (voir shell injection exemples):

    Si vous utilisez une entrée de l'utilisateur comme une nouvelle commande vous avez donné de lui une coquille. C'est beaucoup comme l'injection SQL fournir une coquille dans la base de données pour l'utilisateur.

    Un exemple serait une commande de la forme:

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

    Ce qui peut être facilement exploitée pour exécuter tout du code arbitraire à l'aide de l'entrée: NASTY COMMAND;# pour créer l'éventuelle:

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

    Il ya beaucoup de ces commandes qui peuvent mettre votre système en danger.

    • Je dirais 2. c'est la raison principale.
    InformationsquelleAutor Reut Sharabani
  4. 23

    Pour une raison simple lorsque vous appelez une fonction shell, il crée un sous-shell qui est détruit après votre commande, de sorte que si vous changer de répertoire dans un shell - elle n'affecte pas votre environnement en Python.

    En outre, la création de sous-shell est temps de consommer, donc à l'aide d'OS les commandes directement un impact sur votre performance

    MODIFIER

    J'ai eu quelques synchronisation tests en cours d'exécution:

    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

    Interne de la fonction s'exécute plus de 10 fois plus rapide

    EDIT2

    Il peut y avoir des cas lors de l'appel d'exécutable externe peut donner de meilleurs résultats que les paquets Python - je viens de me rappeler un e-mail envoyé par un de mes collègues que les performances de gzip appelé par le sous-processus a été beaucoup plus élevé que le rendement d'un paquet Python qu'il a utilisés. Mais certainement pas quand on parle de standard de l'OS paquets émulation standard de l'OS commandes

    • Par hasard, est-ce fait avec iPython? Ne pense pas que vous pouvez utiliser les fonctions spéciales début avec % au moyen de l'interprète.
    • yep, c'était iPython - sur Ubuntu. "Magique" %timeit est une bénédiction - bien qu'il existe certains cas - surtout avec de chaîne de formatage - qu'il ne peut pas traiter
    • Ou vous pouvez également faire un script python, puis tapez time <path to script> dans le terminal et il va vous dire le vrai, les utilisateurs et les processus de temps. C'est si vous n'avez pas de iPython et vous avez accès à la ligne de commande Unix.
    • Je ne vois aucune raison de travailler dur, quand j'ai iPython sur ma machine
    • Vrai! J'ai dit que si vous n'avez pas iPython. 🙂
    InformationsquelleAutor volcano
  5. 16

    Coquille d'un appel à l'OS spécifique alors que Python os les fonctions du module sont pas, dans la plupart des cas. Et il éviter la ponte d'un sous-processus.

    • Module Python fonctions aussi frayer de nouvelles sous-processus d'invoquer un nouveau shell interne est exécuté.
    • non-sens, les fonctions du module sont appelés dans le processus de
    • le module os utilise le système sous-jacent appels que la commande shell utilisé, il n'est pas utiliser les commandes shell. Cela signifie que le système d'exploitation système d'appel sont généralement plus sûr et le plus rapide (pas de traitement de chaîne, boo fourche, pas de exec, au contraire, il est juste un noyau d'appel) que les commandes shell. Notez que dans la plupart des cas, l'interpréteur de commandes d'appel et de l'appel système ont souvent similaires ou de même nom, mais il y a documenté séparément; la coquille d'appel est dans l'homme section 1 (la valeur par défaut de l'homme section), tandis que l', de manière équivalente, nommé appel système est dans l'homme, l'article 2 (par exemple, l'homme 2 chmod).
    • Mon mauvais! J'ai eu une mauvaise idée, il me semble. Merci!
    InformationsquelleAutor JoshRomRock
  6. 11

    C'est beaucoup plus efficace. Le "shell" est juste un autre OS binaire qui contient un grand nombre d'appels système. Pourquoi payer les frais généraux de la création de l'ensemble du processus du shell juste pour que seul appel système?

    La situation est encore pire lorsque vous utilisez os.system pour quelque chose qui n'est pas une coque intégrée. Vous démarrez un processus de shell, qui à son tour commence un exécutable qui ensuite (deux processus de loin) fait l'appel système. Au moins subprocess aurait supprimé la nécessité d'une coquille intermédiaire du processus.

    Ce n'est pas spécifique à Python, c'. systemd est une amélioration pour Linux temps de démarrage pour la même raison: il fait le nécessaire appels système lui-même au lieu de pondre un millier d'obus.

    InformationsquelleAutor MSalters