Digamos, por ejemplo, en un programa que me permite seleccionar una carpeta y copiarla en otra ubicación, en un nivel muy básico es que la aplicación ejecuta comandos que podría ejecutar en la terminal o está usando alguna API interna del sistema operativo para hacer ese movimiento. ?
Por favor, ahórrame cualquier respuesta viciosa; Solo tengo curiosidad y estoy totalmente consciente de que puede percibirse como una pregunta que haría un niño de 13 años.
Conceptualmente, siempre utiliza la API del sistema operativo: la pregunta es sólo de qué manera. Hay esencialmente tres opciones.
usando la API del sistema operativo de bajo nivel (llamadas al sistema) directamente. En su ejemplo, la tarea es bastante complicada: obtenga la lista de elementos en la carpeta, verifique el tipo (carpeta, archivo ...), para cada uno de ellos cree el elemento correspondiente en la carpeta de destino, para los archivos lea el contenido del fuente, escriba en el archivo de destino, etc. Dado que la tarea es tan compleja, es fácil equivocarse, por lo que la mayoría de las aplicaciones evitarán esto.
use una biblioteca (API) que simplifique la tarea. Por ejemplo, el marco Apple Cocoa proporciona la clase NSFileManager con el método copyItemAtPath:toPath:error que hace todo el trabajo sucio utilizando API de bajo nivel del OS, por lo que la aplicación no necesita usar la API de bajo nivel en sí misma, sino que puede confiar en algo que Requiere menos trabajo y está siempre presente en el sistema. También es probable que Apple se asegure de que funcione bien.
usa un proceso externo para hacer la tarea. En este caso, el proceso externo utilizará uno de los dos métodos anteriores para realizar el trabajo. La aplicación debe iniciar dicho proceso, monitorearlo y esperar hasta que esté listo. Es probable que dicho proceso se pueda ejecutar como una herramienta de línea de comandos, por lo que este podría ser un comando que puede ejecutar en Terminal. No está garantizado, pero es muy posible.
La mayoría de las aplicaciones usarán la opción 2. porque es más simple que 1. y más segura y eficiente que 3. Para ejecutar un proceso externo, debe configurarlo correctamente y no tiene control sobre lo que hace. Por ejemplo, es mucho más difícil averiguar qué fue exactamente lo que salió mal en caso de una falla y es difícil saber qué está haciendo (por ejemplo, mostrar el progreso). Es por eso que en la mayoría de los casos los desarrolladores probablemente elegirán la opción 2, pero no hay garantía. Un ejemplo notable son las aplicaciones que usan scripts de shell para la personalización, como los instaladores.
Nota de usuario avanzada: puede usar la facilidad dtrace de OS X para averiguar qué está haciendo una aplicación en particular. Por ejemplo, puedes verificar cualquier proceso que esté generando para ver las herramientas que está usando (ver execsnoop ).
Me temo que la respuesta es "depende, pero generalmente la segunda". En realidad, incluso si un programa de GUI ejecuta comandos de terminal, los ejecuta llamando a una API.
Un programa que es simplemente una lista de comandos de terminal se denomina script de shell. Dichos programas pueden ejecutarse en Mac OS X, pero deben ejecutarse en una ventana de Terminal o iniciar un programa que use la GUI si desea ver su salida. Otros programas pueden llamar a programas de línea de comandos a través de API internas.
Si bien la mayoría de las preguntas de desarrollo están fuera de tema para este sitio, un ejemplo que realmente está en tema implica ejecutar Automator.
Una opción dentro de la lista de comandos internos que un programa creado en Automator puede llamar es la capacidad de llamar a un script de shell, o una lista de comandos de Terminal. Pero eso es solo una de las muchas opciones disponibles dentro de su API interna.
Una de las grandes ideas detrás de Unix es (era) que si tuvieras una idea para un programa, primero lo escribirías como un script de shell, esencialmente llamando una serie de comandos.
Luego, si el programa demostró ser útil, podría mejorar su interfaz, hacer que los usuarios lo probaran y, finalmente, cuando esté convencido de que valió la pena, escriba un programa "real".
Esto, por supuesto, fue antes de que las interfaces gráficas de usuario se hicieran cargo, por lo que un "programa" aquí es un comando CLI en sí mismo.
Aún se ve este enfoque en algunos programas modernos, especialmente si muestran información del sistema. ¿Desea crear una aplicación sencilla para enumerar todos los archivos en una carpeta? Simplemente ejecute ls -al , analice el resultado y muéstrelo una tabla. Diviértete con los diversos parámetros, y tienes tu material para la versión 2.0
Una clase de programas que ejecutan comandos de terminal (aunque todo comienza con una llamada a la API) son los entornos de desarrollo de programas integrados como eclipse o Xcode. La colección de herramientas necesarias para el desarrollo del programa es prohibitivamente grande para ser contenida y mantenida para un IDE. En su lugar, crea un makefile (un tipo de script) y lo ejecuta con unix 'make' (o un equivalente) para pasar por el proceso de compilación, enlace, carga y depuración. Make, a su vez, ejecuta el compilador, el enlazador, etc. utilizando sus interfaces de línea de comandos. Esto permite que el IDE sea relativamente independiente del conjunto de herramientas elegido por el programador e insensible a las actualizaciones de las herramientas.
Las aplicaciones pueden ejecutar comandos CLI para realizar una determinada tarea, y algunas realmente lo hacen; pero debido a problemas de eficiencia, los desarrolladores de aplicaciones profesionales evitan ejecutar el comando y prefieren usar las API que el comando utiliza para realizar la tarea requerida.
Lea otras preguntas en las etiquetas macos