do shell script "....
tablier
Membre
2 questions:
quel est l'équivalent en Objective-C de: do shell script "ps -cx" d'applescript
lorsque j'exécute le do shell script, j'arrive à trouvé une description de l'apple event:
AE: 'syso' ID: 'exec' {'----':"ps -cx", &'subj':''null''(), .......... etc
mais je n'arrive pas à déterminer le destinataire de l'AE. Quelqu'un aurait une idée?
quel est l'équivalent en Objective-C de: do shell script "ps -cx" d'applescript
lorsque j'exécute le do shell script, j'arrive à trouvé une description de l'apple event:
AE: 'syso' ID: 'exec' {'----':"ps -cx", &'subj':''null''(), .......... etc
mais je n'arrive pas à déterminer le destinataire de l'AE. Quelqu'un aurait une idée?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
En faisant une recherche sur NSTask (sur google ou même ici, puisqu'on en a déjà parlé) tu trouveras ton bonheur et en particulier des exemples types pour executer un commande terminal, dans ton exemple la commande "ps" avec les arguments "cx".
Par contre je ne sais plus exactement quelle classe permet ça (je pensais à NSWorkspace mais ça n'a pas l'air d'être ça) mais bon, en cherchant bien dans la doc ça se retrouve.
Une bonne adresse à lire en tout cas
Pour info: Mon problème est en fait de trouver la bonne information sur une application (process) que je lance (launchApplication:), pour pouvoir écrire un descripteur d'adresse et lui envoyer quelques milliers d'AppleEvents. Donc il me faut soit son PID, soit son PSN.
Question subsidiaire: PID et PSN sont-ils uniques lors d'une session?
CaD: Si je ferme une application, son PID disparait. Sera-t-il réutilisé par le system dans la même session?
Maintenant :
1) Le PID n'est pas unique par session : rien ne dit qu'un PID qui a déjà été utilisé (mais ne l'est plus) ne sera pas réutilisé plus tard, même dans la même session. En pratique, en général, les numéros de PID s'incrémentent (tu lances une appli A qui a un PID P, si tu lances une autre appli ensuite, il aura certainement le PID P+1, etc), mais c'est juste une constatation, et la seule règle imposée par UNIX c'est que lse PID soient unique, c'est à dire qu'à tout moment chaque PID utilisé ne le soit que par un seul process. D'après cette règle, si un process est quitté, son PID pourra être réutilisé donc.
2) Normalement les AppleEvents sont envoyés à une appli identifiée par son nom (ou son bundleidentifier ou son code créateur). Donc c'est plutôt ce genre d'info qu'il te faut, qu'un PID.
Ces identifiants (nom, bundleIdentifier, ou code créateur) sont communes à toutes les instances de cette appli (si plusieurs instances il y a... ce qui en pratique en général n'est pas possible, du moins si tu lances ton appli par le Finder), et même à toutes les versions (si tu as 2 versions d'une même appli, à 2 endroits différents sur ton disque, cette appli aura sans doute le même nom, en tout cas le même code créateur et le même BundleIdentifier pour les 2 versions). Si tu lances cette appli, que tu la quittes, la relance, la requitte, etc, ces identifiants là ne changeront pas, contrairement au PID par exemple, qui lui changera à chaque lancement.
Et de toute façon ça tombe bien puisque c'est avec ces identifiants (nom de l'appli, ou alors bundleIdentifier, ou alors code créateur), à la fois :
- que tu appelle launchApplication de la classe NSWorkspace
- que tu indique le destinataire de ton AppleEvent (dans la structure de l'AppleEvent il y a un endroit pour mettre le code créateur de l'appli destinataire)
Donc finalement, le PID, je ne pense pas qu'il te soit trop utile... (ni le PSN d'ailleurs)
Si si cher Ali t'as raison ,
c'est bien avec NSWorkspace qu'on peut obtenir cette liste il me semble.
D'après vos réponses, je ne vois pas comment savoir qu'une application a été fermée puis réouverte. Je pensais comparer les PID pris à deux instants différents. Mais d'après vos observations sur le PID cela ne parait pas la bonne solution.
Y-a-t-il une manière de faire cela?
Par ex.:
NSWorkspaceDidTerminateApplicationNotification est accompagné d'un NSDic comprenant le PID le nom de l'appli., son Path etc...
De même que NSWorkspaceDidLaunchApplicationNotification.
En observant en continue ces notifications, rien ne t'échappe sur les appli lancées ou quittées en direct.
T'as même un NSWorkspaceWillLaunchApplicationNotification qui contient les mêmes infos et t'averti carrément avant le lancement réel de l'appli.