interfaz gráfica de usuario combinada y línea de comandos aplicación OS X

Question

¿Es posible crear una sola aplicación Mac OS X que se pueda ejecutar estrictamente desde la línea de comandos * nix (usando stdin/stdout, desde la consola Terminal o mediante ssh, etc. .), pero también ser ejecutable desde un ícono de la aplicación y usar la GUI de Mac para toda la interacción del usuario (no se requiere terminal). ¿Si es así, cómo?

Ya puedo lograr algo como esto utilizando dos ejecutables, uno de interfaz gráfica de usuario para el otro, con tuberías, tomas de corriente, memoria compartida, o Applescript (et.al.) para la comunicación. La pregunta es si puedo hacer esto usando un solo espacio de proceso de aplicación única y ejecutable.

¿Hay alguna manera de hacer esto sin pasar un nuevo argumento de línea de comandos al ejecutable de la línea de comandos? (ya que hay problemas heredados relacionados con el uso de la aplicación de línea de comandos).

Answer 1

Sí, Simplemente agregue un interruptor --command-line al programa. Inicie la GUI normal a menos que se pase --command-line como argumento al ejecutar.

./myprog --command-line 

Eso es todo lo que hay que hacer.

Answer 2

Esto debe tomarse con un grano de sal ya que esto es lo que haría en una aplicación .Net, creo que la idea se puede lograr en otros idiomas en otras plataformas.

Crearía una aplicación de consola que aún utiliza todas las clases de la GUI. Cuando se inicia el programa, según los criterios que determinan si se trata de una instancia de GUI en lugar de una instancia de línea de comando, inicio una GUI o comienzo en la interfaz de línea de comando.

Lo principal es que tiene alguna condición que determina cuándo desea mostrar una GUI en lugar de una línea de comando. Tal vez a través de una variable del sistema sobre la sesión (¿es una sesión ssh, luego línea de comandos, de lo contrario GUI).

Answer 3

Yo diría que no será posible de la manera que usted espera. Las aplicaciones GUI OSX son en realidad paquetes de aplicaciones, es decir, en realidad son directorios que contienen lotes de recursos además del ejecutable real. Ciertamente no puede ejecutar estos paquetes en un shell como si fueran ejecutables de línea de comandos (por ejemplo, no puede hacer ./MyApplication.app --some-option en el intérprete de comandos de su shell, ya que su shell no sabe cómo ejecutar un directorio), aunque probablemente sepa que usted puede ejecutarlos como GUI a través de open MyApplication.app. Ahora, puede llegue al ejecutable real en el interior del paquete, y puede ser posible obtener que ejecutable para trabajar como un ejecutable CLI - hablando de mi culo aquí ya que no tengo experiencia real con las herramientas Xcode y su sistema de compilación, pero podría ser posible que el ejecutable real funcione en la invocación de CLI y GUI.

Aún así, eso no sería muy útil, ya que esos ejecutables están enterrados dentro del paquete de aplicaciones y generalmente no son accesibles directamente en un shell (es decir, ciertamente no están en su $ PATH, entonces tendrá que invocar ellos como algo así como ./MyApplication.app/Contents/MacOS/actualbinaryname). El enfoque habitual que he visto en la naturaleza es proporcionar un ejecutable de CLI independiente incluido con su aplicación, que generalmente se instala en una ubicación adecuada (por ejemplo,/usr/local/bin) por un instalador o haciendo clic en un botón de la aplicación preferencias. Esos archivos ejecutables CLI se encargan de la interfaz con la aplicación GUI, si eso es lo que pretende hacer (no está claro a partir de su pregunta).

Answer 4

No estoy 100% seguro de si esto funcionará, pero la documentación de la clave LSEnvironment en Info.plist parece indicar que las variables de entorno especificadas solo se definirán cuando el Finder inicie la aplicación.

Si definiera una variable en LSEnvironment (llamémosla MYAPP_GUI) y verifique su valor en el inicio, debería existir cuando se utiliza Finder y no cuando se usa Terminal. Eso te dirá si mostrar o no GUI o usar stdio

Answer 5

Lo que estás buscando, creo, es una forma de determinar si te lanzan desde la GUI o desde la línea de comando. Una forma simple sería obtener su identificador de proceso principal. Si es un proceso de GUI, se inicia mediante launchd (la sesión de usuario se inicia). Si usted es una línea de comando, entonces un intérprete de comandos o secuencia de comandos lo ha iniciado (en cualquier caso, NO se inició).

Ahora, cómo hacerlo - una forma sencilla sería utilizar la llamada al sistema proc_info (# 336), que está convenientemente envuelto por libproc (marque <libproc.h> Específicamente, usted quiere proc_bsdinfo (ver <sys/proc_info.h>) que tiene la. campo pbi_ppid para especificar su padre (y pbi_comm del padre le dirá su nombre - para ver si se lance). Puede implementar la funcionalidad de línea de comando marcando su padre antes de entrar en NSApplicationMain.

(Como en otro respuestas, su binario terminará en su .app/Contents/MacOS/<binary>, entonces sí, un enlace simbólico tiene sentido)

Answer 6

Disculpe si me falta el punto, pero si está utilizando el objetivo-C, no es parte de la respuesta para usar la clase NSProcessInfo en el objetivo-C y examinar la variable 'argumentos' para determinar si se han pasado argumentos, y luego tomar una decisión en el código sobre qué hacer a continuación?