Par exemple, dans un programme qui me permet de sélectionner un dossier et de le copier à un autre endroit, cette application exécute-t-elle des commandes que je pourrais exécuter dans un terminal ou utilise-t-elle une API interne du système d'exploitation pour effectuer ce déplacement ?
Je vous prie de m'épargner toute réponse vicieuse ; je suis simplement curieux et tout à fait conscient que cela peut être perçu comme une question que poserait un enfant de 13 ans.
Conceptuellement, il utilise toujours l'API du système d'exploitation - la question est seulement de savoir de quelle manière. Il existe essentiellement trois options.
en utilisant directement l'API de bas niveau du système d'exploitation (appels système). Dans votre exemple, la tâche est assez complexe : obtenir la liste des éléments du dossier, vérifier le type (dossier, fichier...), pour chacun d'entre eux, créer l'élément correspondant dans le dossier cible, pour les fichiers, lire le contenu de la source, écrire dans le fichier cible, etc. Comme la tâche est très complexe, il est facile de se tromper, c'est pourquoi la plupart des applications évitent cela.
utiliser une bibliothèque (API) qui simplifie la tâche. Par exemple, le cadre Cocoa d'Apple fournit NSFileManager avec la classe copyItemAtPath:toPath:error qui fait tout le sale boulot en utilisant l'API de bas niveau du système d'exploitation, de sorte que l'application n'a pas besoin d'utiliser elle-même l'API de bas niveau mais peut s'appuyer sur quelque chose qui demande moins de travail et qui est toujours présent dans le système. De plus, Apple est susceptible de s'assurer que cela fonctionne bien.
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 lancer ce 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, et qu'il s'agisse donc d'une commande que vous pouvez exécuter dans le Terminal. Ce n'est pas garanti, mais très possible.
La plupart des applications utiliseront l'option 2. car elle est plus simple que l'option 1. et plus sûre et efficace que l'option 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 passé en cas d'échec et de savoir ce qu'il fait (par exemple, montrer la progression). 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 celui des applications qui utilisent des scripts pour la personnalisation - comme les installateurs.
Note pour l'utilisateur avancé : vous pouvez utiliser dtrace d'OS X pour savoir ce que fait une application particulière. Par exemple, vous pouvez vérifier tous les processus qu'elle génère afin de voir les outils qu'elle utilise (cf. execsnoop ).
J'ai bien peur que la réponse soit "ça 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 shell script. De tels programmes peuvent s'exécuter dans Mac OS X, mais ils doivent soit s'exécuter dans une fenêtre Terminal, soit lancer un programme qui utilise l'interface graphique si vous voulez voir leur sortie. D'autres programmes peuvent appeler des programmes en ligne de commande par le biais d'API internes.
Alors que la plupart des questions relatives au développement sont hors sujet pour ce site, un exemple qui est en fait sur le sujet concerne l'exécution d'Automator.
Une option parmi 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 là qu'une des nombreuses options disponibles au sein de son API interne.
Une des grandes idées derrière Unix est (était) que si vous avez une idée pour un programme, alors vous l'écrivez d'abord comme un shell script - essentiellement en appelant une série de commandes.
Ensuite, si le programme s'avérait utile, vous pouviez améliorer son interface, le faire tester par des utilisateurs, et enfin, lorsque vous étiez convaincu que cela en valait la peine, écrire un "vrai" programme.
C'était, bien sûr, avant que les interfaces graphiques ne prennent le dessus, donc un "programme" ici est une commande CLI en soi.
Vous voyez encore cette approche dans certains programmes modernes, surtout s'ils affichent des informations sur le système. Vous voulez construire une application simple pour lister tous les fichiers d'un dossier ? Il suffit d'exécuter ls -al , analyser le résultat et le présenter sous forme de tableau. Amusez-vous avec les différents paramètres, et vous avez votre matériel pour la version 2.0.
Les applications peuvent exécuter des commandes CLI pour effectuer une certaine tâche, et certaines le font effectivement ; mais, pour des raisons d'efficacité, les développeurs d'applications professionnels évitent d'exécuter la commande et préfèrent utiliser la fonction APIs que la commande utilise pour effectuer la tâche requise.
Une catégorie de programmes qui exécutent des commandes de terminal (même si tout commence par un appel d'API) est constituée par les environnements intégrés de développement de programmes tels qu'eclipse ou Xcode. La collection d'outils nécessaires au développement de programmes est prohibitivement grande pour être contenue dans, et maintenue pour, un IDE. Au lieu de cela, il construit un makefile (une sorte de script) et l'exécute avec unix 'make' (ou un équivalent) pour passer par le processus de compilation, liaison, chargement et débogage. Make, à son tour, exécute le compilateur, l'éditeur de liens, etc. en utilisant leurs interfaces de ligne de commande. Ceci permet à l'IDE d'être relativement indépendant du jeu d'outils choisi par le programmeur, et insensible aux mises à jour des outils.
LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.
