Dans leur forme la plus simple, les programmes exécutent-ils simplement des commandes de terminal?

Disons par exemple que dans un programme, il me permet de sélectionner un dossier et de le copier vers un autre emplacement.À un niveau très basique, cette application exécute-t-elle des commandes que je pourrais exécuter dans le terminal ou utilise-t-elle une API de système d'exploitation interne pour effectuer ce déplacement?

Veuillez m'épargner toutes les réponses vicieuses; Je suis simplement curieux et totalement conscient que cela peut être perçu comme une question qu'un jeune de 13 ans poserait.

Conceptuellement, il utilise toujours l'API OS - la question n'est que de quelle manière. Il existe essentiellement trois options.

1. en utilisant directement l'API OS de bas niveau (appels système). Dans votre exemple, la tâche est assez compliquée: obtenir la liste des éléments du dossier, vérifier le type (dossier, fichier ...), pour chacun d'eux créer l'élément correspondant dans le dossier cible, pour les fichiers lire le contenu du source, écrivez dans le fichier cible, etc. Étant donné que la tâche est si complexe, il est facile de se tromper, de sorte que la plupart des applications éviteront cela.

2. utiliser une bibliothèque (API) qui simplifie la tâche. Par exemple, le framework Apple Cocoa fournit à la NSFileManagerclasse la copyItemAtPath:toPath:errorméthode qui fait tout le sale boulot en utilisant l'API du système d'exploitation de bas niveau, de sorte que l'application n'a pas besoin d'utiliser l'API de bas niveau elle-même, mais peut s'appuyer sur quelque chose qui nécessite moins de travail et est toujours présent dans le système. Apple est également susceptible de s'assurer que cela fonctionne bien.

3. utiliser un processus externe pour effectuer la tâche. Dans ce cas, le processus externe utilisera l'une des deux méthodes ci-dessus pour effectuer le travail. L'application doit démarrer un tel processus, le surveiller et attendre qu'il soit terminé. Il est probable qu'un tel processus puisse être exécuté en tant qu'outil de ligne de commande, il s'agit donc probablement d'une commande que vous pouvez exécuter dans Terminal. Ce n'est pas garanti, mais très possible.

La plupart des applications utiliseront l'option 2. car elle est plus simple que 1. et plus sûre et efficace que 3. Pour exécuter un processus externe, vous devez le configurer correctement et vous n'avez aucun contrôle sur ce qu'il fait. Par exemple, il est beaucoup plus difficile de comprendre ce qui s'est exactement passé en cas d'échec et il est difficile de savoir ce qu'il fait (par exemple, montrer les progrès). C'est pourquoi dans la plupart des cas, les développeurs choisiront probablement l'option 2, mais il n'y a aucune garantie. Un exemple notable est les applications qui utilisent des scripts shell pour la personnalisation - comme les programmes d'installation.

Remarque avancée pour l'utilisateur: vous pouvez utiliser la fonctionnalité dtraced'OS X pour savoir ce que fait une application particulière. Par exemple, vous pouvez vérifier tous les processus qu'il génère afin de voir les outils qu'il utilise (voir execsnoop).

J'ai bien peur que la réponse soit "cela dépend, mais généralement la seconde". En fait, même si un programme GUI exécute des commandes de terminal, il les exécute en appelant une API.

Un programme qui est simplement une liste de commandes de terminal est appelé un script shell. Ces programmes peuvent s'exécuter sous Mac OS X, mais ils doivent soit s'exécuter dans une fenêtre de terminal, soit lancer un programme qui utilise l'interface graphique si vous souhaitez voir leur sortie. D'autres programmes peuvent appeler des programmes en ligne de commande via des API internes.

Bien que la plupart des questions de développement soient hors sujet pour ce site, un exemple qui est réellement sur le sujet implique l'exécution d'Automator.

Une option dans la liste des commandes internes qu'un programme créé dans Automator peut appeler est la possibilité d'appeler un script shell ou une liste de commandes Terminal. Mais ce n'est que l'une des nombreuses options disponibles dans son API interne.

L'une des grandes idées derrière Unix est (était) que si vous avez une idée pour un programme, vous devez d'abord l'écrire en tant que script shell - appelant essentiellement une série de commandes.

Ensuite, si le programme s'avérait utile, vous pouviez améliorer son interface, demander aux utilisateurs de le tester, et enfin, lorsque vous étiez convaincu que cela en valait la peine, écrivez un "vrai" programme.

Bien sûr, c'était avant que les interfaces utilisateur graphiques ne prennent le relais, donc un "programme" est ici une commande CLI en soi.

Vous voyez toujours cette approche dans certains programmes modernes, surtout s'ils affichent des informations système. Vous voulez créer une application simple pour répertorier tous les fichiers d'un dossier? Il suffit d'exécuter ls -al, d'analyser le résultat et de lui montrer un tableau. Amusez-vous avec les différents paramètres, et vous avez votre matériel pour la version 2.0

Les environnements de développement de programmes intégrés tels qu'eclipse ou Xcode constituent une classe de programmes qui exécutent des commandes de terminal (même si tout commence par un appel d'API). La collection d'outils nécessaires au développement du programme est d'une taille prohibitive pour être contenue dans un IDE et maintenue pour lui. Au lieu de cela, il crée un makefile (une sorte de script) et l'exécute avec unix 'make' (ou un équivalent) pour parcourir le processus de compilation, de liaison, de chargement et de débogage. Make, à son tour, exécute le compilateur, l'éditeur de liens, etc. à l'aide de leurs interfaces de ligne de commande. Cela permet à l'EDI d'être relativement indépendant de l'ensemble d'outils choisi par le programmeur et insensible aux mises à jour des outils.

Les applications peuvent exécuter des commandes CLI pour effectuer une certaine tâche, et certaines le font en fait; mais en raison de problèmes d'efficacité, les développeurs d'applications professionnelles évitent d'exécuter la commande et utilisent plutôt les API que la commande utilise pour effectuer la tâche requise.