Applescript et multitache, C'est possible?

[__toto__maison]

C'est une question que je me pose pour un projet de front end d'un soft libre.
Donc dans ce cas, j'aurai par exemple une liste de fichier a traité. Comme j'utilise un soft en ligne de commande, ca vas donner du do shell script.

Comment faire pour lancer les do shell script a la suite sans attendre la réponse, et ne pas etre obliger d'attendre que le fichier précédent ait été traité.

Si qq a une idée....

Les scripts objet peuvent-t-il faire ca?

[Doom Hammer]

ignoring application responses
do shell script "blabla"
...
do shell script "blabla"
end ignoring

Essaie ça, normalement dans ce cas, AppleScript d'attend plus de recevoir une réponse de la part de l'application pilotée pour passer à la commande suivante.
A vérifier avec les do shell script.

[ddrix]

Oui, c'est possible mais ça n'est pas évident à trouver !
On penserait qu'il suffirait de mettre

CODE

do shell script "truc &"

mais en fait c'est

CODE

do shell script "truc > /dev/null 2>&1 &"

vu dans une technote : http://developer.apple.com/technotes/tn2002/tn2065.html

Q: I want to start a background server process; how do I make do shell script not wait until the command completes?

A: Use "do shell script "command > file_path 2>&1 &"". do shell script will return immediately with no result and your AppleScript script will be running in parallel with your shell script. The shell script's output will go into file_path; if you don't care about the output, use "/dev/null". There is no direct support for getting or manipulating the background process from AppleScript, but see the next question.

Ce message a été modifié par ddrix - 8 Sep 2004, 22:38.

[__toto__maison]

truc > /dev/null 2>&1

C'est pour envoyer le flux de sortie de la commande vers une autre sortie.

La j'ai pas de mac sous la main, mais si ton truc marche Doom, alors je dois pouvoir lancer une commande en enregistrant la sortie de la commande dans un fichier >>log-tache.txt
Donc faire ma commade sans perdre la possibilité de suivre le résultat.
A moins qu'il ne soit possible de lancer la commnde avec le & ET de faire une sortie vers un fichier.

Merci !

Bon, ben la suite ca sera quand j'aurais la becanne sous la main.

Ce message a été modifié par __toto__maison - 8 Sep 2004, 20:36.

[manu_t]

si tu lis bien le texte de Apple, la bonne commande serait plutôt la suivante :

CODE

truc > /dev/null 2>&1 &

Emmanuel

Ce message a été modifié par manu_t - 8 Sep 2004, 20:51.

[ddrix]

Effectivement faute de frappe de ma part j'avais oublié le dernier &

Mais je confirme que cela marche en faisant

CODE

do shell script "truc > /dev/null 2>&1 &"

Je l'utilise dans un de mes scripts (un truc bizarre où mon applescript appelle un script perl qui exécute de l'applescript - et pour cela il faut que l'exécution du premier applescript soit finie, sinon on a un deadlock).

La partie importante a l'air d'être le "2>&1 &", quelqu'un sait ce que ça veut dire en sh au fait ? juste par curiosité...

Ce message a été modifié par ddrix - 8 Sep 2004, 22:44.

[Dam-le-Damdam]

En tout cas, c'est intéressant comme info, car les "do shell" bloquait les autres process, ca ne doit plus être le cas maintenant, non ??? Car j'avais un script perl qui était lancé par mon AppleScript et qui utilisait 80% des ressources au moins !!!! (backup d'une library iTunes avec conversion pour Mac OS 9).

[ddrix]

Je ne pense pas que ça change quelque chose au niveau du système en général, ça ne fait que séparer l'exécution de l'applescript et du shell script. C'est normal qu'un process prenne autant de CPU qu'il peut, mais il ne bloque pas les autres process pour autant, c'est une question de priorités.

[manu_t]

CODE

truc > /dev/null 2>&1 &"

La partie importante a l'air d'être le "2>&1 &", quelqu'un sait ce que ça veut dire en sh au fait ? juste par curiosité...
[right][snapback]840263[/snapback][/right]

explications :

CODE

> /dev/null

redirige la sortie standard vers le fichier /dev/null (donc ici vers les oubliettes, mais on peut y mettre un vrai fichier)

CODE

2>&1

redirige le flux d'erreurs standard (2) vers le flux standard 1 (c'est à dire la sortie standard qui a déjà été redirigée

CODE

&

permet de séparer l'exécution de la commande du shell qui l'a lancé.
C'est en fait cet argument qui permet de ne pas bloquer le script, le 2 autres paramètres servent simplement à effacer tout ce que pourrait écrire la commande.

De façon générale, la redirection s'écrit comme cela :

CODE

commande < fichier_entrees.txt > fichier-sorties.txt 2>fichier_erreurs.txt

pour plus d'infos :

CODE

man bash

Emmanuel

Ce message a été modifié par manu_t - 9 Sep 2004, 22:23.

[ddrix]

merci pour les explications
Mais ce qui est bizarre c'est qu'un simple

CODE

do shell script "truc &"

ne marche pas...
Il faut qu'il y ait "> /dev/null" ET "2>&1" en plus du & final, sans doute parce que la commande do shell script essaye de récupérer la sortie ?

Ce message a été modifié par ddrix - 9 Sep 2004, 23:03.

[Dam-le-Damdam]

merci pour les explications
Mais ce qui est bizarre c'est qu'un simple

CODE

do shell script "truc &"

ne marche pas...
Il faut qu'il y ait "> /dev/null" ET "2>&1" en plus du & final, sans doute parce que la commande do shell script essaye de récupérer la sortie ?
[right][snapback]841673[/snapback][/right]

Logique, sinon ton script attend un résultat... Là non, donc il peut continuer ce qu'il doit faire.

[Doom Hammer]

ignoring application responses
set le_resultat to do shell script "blabla"
...
set le_resultat2 to do shell script "blabla"
end ignoring

Tu peux récupérer les résultats comme ceci et tout devrait se faire en même temps.
A tester...

[le grimpeur]

Salut Doom!!!
Eh ben j'ai testé et non, il faut faire un truc avec top comme je te l'avait expliqué à l'AE.
En fait, on ignore la reponse avec la routine ignore, et et lance dans une boucle non bloquante une commande top avec certains paramètres, pour récupérer l'ID du process et ainsi pouvoir en connaître et controler l'état à l'aide de signaux POSIX. (ça touche au C mais c'est compréhensible, rappel : signaux POSIX = SIGTERM,SIGKILL...pour stopper le process).
Ils parlaient de ça sur la mailing list applescript d'apple.à chercher pour avoir les détails..

Si qqun à une soluce fonctionelle plus simple (avec un appel OBJ-C ou java à mon avis), faite nous signe

[ddrix]

Pour ce qui est de récupérer le pid il y a une méthode plus simple dans la même technote :

Q: I have started a background process; how do I get its process ID so I can control it with other shell commands?

A: You can use a feature of sh to do this: the special variable $! is the ID of the most recent background command, so you can echo it as the last command in your shell script, like this:

CODE

do shell script "my_command > /dev/null 2>&1 & echo $!"
-- result: 621
set pid to the result
do shell script "renice +20 -p " & pid
-- change my_command's scheduling priority.
do shell script "kill " & pid
-- my_command is terminated.

Après pour contrôler, je ne vois en effet pas d'autre solution que des signaux POSIX ou une hypothétique ScriptingAddition...

Ce message a été modifié par ddrix - 11 Sep 2004, 23:27.

[Doom Hammer]

Salut Doom!!!
Eh ben j'ai testé et non, il faut faire un truc avec top comme je te l'avait expliqué à l'AE.

Ah... ça marche par exemple pour dupliquer plusieurs éléments en même dans le Finder par exemple. Pour des shell script ça doit être différent.