donc l'argument "dummy=empty" n'est là, comme son nom l'indique, que parce que le premier argument disparaît, je ne sais où...
autre chose, ce matin j'ai utilisé un script "mover" qui "WatchPaths" un dossier, si qqc dedans ça le met dans un autre dossier, ça a marché impeccable et maintenant, je n'arrive plus à le lancer :
~%> launchctl load /Users/yvon/Library/LaunchAgents/com.afp548.mover.plist nothing found to load
il faut dire que j'ai fait un peu de nettoyage et que, la première fois où je l'ai relancé, il ne pouvait pas tourner because j'avais déplacé le script.
est-ce que ce serait une sorte de blacklist pour launchd ??? il enregistrerait les trucs "pas bon" ???
faudrait redémarrer ou trouver une fonction de launchd qui lui demenderait de nettoyer ça ???
amha qqc dans ce goût doit exister... -- une bévue
Matt <hfrarg@syrius.org.invalid> wrote:
On le trouve dans "Essentials.pkg"
1ière tentative de re-install : "veuillez ré-essayer l'installation"...
2ième pareille...
Mais que fais-tu donc à ton Mac OS X ?
rien de spécial @#§&?!
bon enfin ce matin j'ai ajouté un daemon "com.apple.launchd_debugd"
serait-ce lié ???
à part ça j'ai toujours mon pb avec un args qui passe à l'as :
donc l'argument "dummy=empty" n'est là, comme son nom l'indique, que
parce que le premier argument disparaît, je ne sais où...
autre chose, ce matin j'ai utilisé un script "mover" qui "WatchPaths" un
dossier, si qqc dedans ça le met dans un autre dossier, ça a marché
impeccable et maintenant, je n'arrive plus à le lancer :
~%> launchctl load
/Users/yvon/Library/LaunchAgents/com.afp548.mover.plist
nothing found to load
il faut dire que j'ai fait un peu de nettoyage et que, la première fois
où je l'ai relancé, il ne pouvait pas tourner because j'avais déplacé le
script.
est-ce que ce serait une sorte de blacklist pour launchd ??? il
enregistrerait les trucs "pas bon" ???
faudrait redémarrer ou trouver une fonction de launchd qui lui
demenderait de nettoyer ça ???
amha qqc dans ce goût doit exister...
--
une bévue
donc l'argument "dummy=empty" n'est là, comme son nom l'indique, que parce que le premier argument disparaît, je ne sais où...
autre chose, ce matin j'ai utilisé un script "mover" qui "WatchPaths" un dossier, si qqc dedans ça le met dans un autre dossier, ça a marché impeccable et maintenant, je n'arrive plus à le lancer :
~%> launchctl load /Users/yvon/Library/LaunchAgents/com.afp548.mover.plist nothing found to load
il faut dire que j'ai fait un peu de nettoyage et que, la première fois où je l'ai relancé, il ne pouvait pas tourner because j'avais déplacé le script.
est-ce que ce serait une sorte de blacklist pour launchd ??? il enregistrerait les trucs "pas bon" ???
faudrait redémarrer ou trouver une fonction de launchd qui lui demenderait de nettoyer ça ???
amha qqc dans ce goût doit exister... -- une bévue
pere.noel
Matt wrote:
Que dirais-tu de lire le man de launchd.plist ? C'est quand même pas la mer à boire et aurait dû être le point de départ pour ton premier agent.
le truc est que j'espérait récupérer une hash de la plist, et comme j'arrivait bien à lire cette hash (<dict/>) depuis mon script ruby je n'ai pas du tout pensé que le pb venait de là.
je ne m'en suis aperçu que ce matin...
m'enfin j'arrive pas à installer le man launchd.plist... -- une bévue
Matt <hfrarg@syrius.org.invalid> wrote:
Que dirais-tu de lire le man de launchd.plist ? C'est quand même pas la
mer à boire et aurait dû être le point de départ pour ton premier agent.
le truc est que j'espérait récupérer une hash de la plist, et comme
j'arrivait bien à lire cette hash (<dict/>) depuis mon script ruby je
n'ai pas du tout pensé que le pb venait de là.
je ne m'en suis aperçu que ce matin...
m'enfin j'arrive pas à installer le man launchd.plist...
--
une bévue
Que dirais-tu de lire le man de launchd.plist ? C'est quand même pas la mer à boire et aurait dû être le point de départ pour ton premier agent.
le truc est que j'espérait récupérer une hash de la plist, et comme j'arrivait bien à lire cette hash (<dict/>) depuis mon script ruby je n'ai pas du tout pensé que le pb venait de là.
je ne m'en suis aperçu que ce matin...
m'enfin j'arrive pas à installer le man launchd.plist... -- une bévue
pere.noel
Luc Heinrich wrote:
Ah, oui effectivement j'avais pas percuté que LAUNCHD_PLIST pouvait être un path avec des blancs :)
c'est super launchd !!!
je vais pouvoir me passer des threads (foireuses en RubyCocoa)... -- une bévue
Luc Heinrich <luc@honk-honk.com> wrote:
Ah, oui effectivement j'avais pas percuté que LAUNCHD_PLIST pouvait être
un path avec des blancs :)
c'est super launchd !!!
je vais pouvoir me passer des threads (foireuses en RubyCocoa)...
--
une bévue
Ah, oui effectivement j'avais pas percuté que LAUNCHD_PLIST pouvait être un path avec des blancs :)
c'est super launchd !!!
je vais pouvoir me passer des threads (foireuses en RubyCocoa)... -- une bévue
laurent.pertois
Matt wrote:
On Wed, 2 Aug 2006 23:56:35 +0200, Laurent Pertois wrote:
PS : attention, il faut toujours donner tous les chemins dans launchd.
Juste pour charger ou décharger ;)
J'ai eu des soucis dans des scripts dans lesquels j'appelais pourtant des commandes courantes, mais bon, depuis je refais le PATH en début de script :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Matt <hfrarg@syrius.org.invalid> wrote:
On Wed, 2 Aug 2006 23:56:35 +0200,
Laurent Pertois <laurent.pertois@alussinan.org> wrote:
PS : attention, il faut toujours donner tous les chemins dans launchd.
Juste pour charger ou décharger ;)
J'ai eu des soucis dans des scripts dans lesquels j'appelais pourtant
des commandes courantes, mais bon, depuis je refais le PATH en début de
script :)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
On Wed, 2 Aug 2006 23:56:35 +0200, Laurent Pertois wrote:
PS : attention, il faut toujours donner tous les chemins dans launchd.
Juste pour charger ou décharger ;)
J'ai eu des soucis dans des scripts dans lesquels j'appelais pourtant des commandes courantes, mais bon, depuis je refais le PATH en début de script :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
pere.noel
Matt wrote:
Bref, sur des fichiers contenus dans Essentials.pkg ne sont plus sur ta machine, je te conseille très vivement de réinstaller un système tout beau tout propre.
è ce point là ! (?)
je vais faire une clean install asap... -- une bévue
Matt <hfrarg@syrius.org.invalid> wrote:
Bref, sur des fichiers contenus dans Essentials.pkg ne sont plus sur ta
machine, je te conseille très vivement de réinstaller un système tout beau
tout propre.
è ce point là ! (?)
je vais faire une clean install asap...
--
une bévue
Bref, sur des fichiers contenus dans Essentials.pkg ne sont plus sur ta machine, je te conseille très vivement de réinstaller un système tout beau tout propre.
è ce point là ! (?)
je vais faire une clean install asap... -- une bévue
pere.noel
Matt wrote:
Fais ça propre. Sauvegarde de tes données, on nettoie bien son disque puis réinstallation d'un système sain.
bon enfin ce matin j'ai ajouté un daemon "com.apple.launchd_debugd" serait-ce lié ???
Aucune idée. Que fait-il ce démon ?
ça :
<http://cjoint.com/data/idxwMdBrNS.htm>
à part ça j'ai toujours mon pb avec un args qui passe à l'as :
[...]
donc l'argument "dummy=empty" n'est là, comme son nom l'indique, que parce que le premier argument disparaît, je ne sais où...
Le premier argument : <string>DEBUGG=true</string> disparaît ? À quoi te sert-il celui-là ?
oui oui, le premier arg disparaît c'est pour cela que j'en met un "dummy", comme il disparaît...
La flag qui active le débogage de launchd(8) c'est :
<key>Debug</key> <true/>
ah ok, merci pour ce tuyau...
[...]
Bon va falloir qu'une fois pour toute tu *lises* la documentation de launchd(8) (j'imagine que lorsque tu as acheté ton nouveau four de cuisine, tu as lu son manuel pour éviter de foutre le feu à tes plats, non alors pourquoi tu fais pas de même avec les programmes que tu utilises ?)
Sans l'utilisation de "-w", le flag "Disabled" reste activé donc consigné dans ton plist :
<key>Disabled</key> <true/>
oui, oui, c'était bien ça, je m'en suis aperçu entre-temps.
Donc une fois ton démon chargé, tu le lance avec :
$ launchctl start com.afp548.mover
oui, oui, j'avais pigé, j'en suis à mon 2ième "daemon".
ce que je trouve surprenant est que le "même" script activé par launchd est nettement plus rapide qu'en "standard", y aurait-il une explication, question priorité, pourtant, j'ai mis : <key>LowPriorityIO</key> <true/>
et mon "script" fait appel à du ruby faisant appel à du shell + de l'AppleScript...
je trouve ça super launchd ;-) -- une bévue
Matt <hfrarg@syrius.org.invalid> wrote:
Fais ça propre.
Sauvegarde de tes données, on nettoie bien son disque puis réinstallation
d'un système sain.
bon enfin ce matin j'ai ajouté un daemon "com.apple.launchd_debugd"
serait-ce lié ???
Aucune idée.
Que fait-il ce démon ?
ça :
<http://cjoint.com/data/idxwMdBrNS.htm>
à part ça j'ai toujours mon pb avec un args qui passe à l'as :
[...]
donc l'argument "dummy=empty" n'est là, comme son nom l'indique, que
parce que le premier argument disparaît, je ne sais où...
Le premier argument : <string>DEBUGG=true</string> disparaît ?
À quoi te sert-il celui-là ?
oui oui, le premier arg disparaît c'est pour cela que j'en met un
"dummy", comme il disparaît...
La flag qui active le débogage de launchd(8) c'est :
<key>Debug</key>
<true/>
ah ok, merci pour ce tuyau...
[...]
Bon va falloir qu'une fois pour toute tu *lises* la documentation de
launchd(8) (j'imagine que lorsque tu as acheté ton nouveau four de
cuisine, tu as lu son manuel pour éviter de foutre le feu à tes plats,
non alors pourquoi tu fais pas de même avec les programmes que tu
utilises ?)
Sans l'utilisation de "-w", le flag "Disabled" reste activé donc consigné
dans ton plist :
<key>Disabled</key>
<true/>
oui, oui, c'était bien ça, je m'en suis aperçu entre-temps.
Donc une fois ton démon chargé, tu le lance avec :
$ launchctl start com.afp548.mover
oui, oui, j'avais pigé, j'en suis à mon 2ième "daemon".
ce que je trouve surprenant est que le "même" script activé par launchd
est nettement plus rapide qu'en "standard", y aurait-il une explication,
question priorité, pourtant, j'ai mis :
<key>LowPriorityIO</key>
<true/>
et mon "script" fait appel à du ruby faisant appel à du shell + de
l'AppleScript...
Fais ça propre. Sauvegarde de tes données, on nettoie bien son disque puis réinstallation d'un système sain.
bon enfin ce matin j'ai ajouté un daemon "com.apple.launchd_debugd" serait-ce lié ???
Aucune idée. Que fait-il ce démon ?
ça :
<http://cjoint.com/data/idxwMdBrNS.htm>
à part ça j'ai toujours mon pb avec un args qui passe à l'as :
[...]
donc l'argument "dummy=empty" n'est là, comme son nom l'indique, que parce que le premier argument disparaît, je ne sais où...
Le premier argument : <string>DEBUGG=true</string> disparaît ? À quoi te sert-il celui-là ?
oui oui, le premier arg disparaît c'est pour cela que j'en met un "dummy", comme il disparaît...
La flag qui active le débogage de launchd(8) c'est :
<key>Debug</key> <true/>
ah ok, merci pour ce tuyau...
[...]
Bon va falloir qu'une fois pour toute tu *lises* la documentation de launchd(8) (j'imagine que lorsque tu as acheté ton nouveau four de cuisine, tu as lu son manuel pour éviter de foutre le feu à tes plats, non alors pourquoi tu fais pas de même avec les programmes que tu utilises ?)
Sans l'utilisation de "-w", le flag "Disabled" reste activé donc consigné dans ton plist :
<key>Disabled</key> <true/>
oui, oui, c'était bien ça, je m'en suis aperçu entre-temps.
Donc une fois ton démon chargé, tu le lance avec :
$ launchctl start com.afp548.mover
oui, oui, j'avais pigé, j'en suis à mon 2ième "daemon".
ce que je trouve surprenant est que le "même" script activé par launchd est nettement plus rapide qu'en "standard", y aurait-il une explication, question priorité, pourtant, j'ai mis : <key>LowPriorityIO</key> <true/>
et mon "script" fait appel à du ruby faisant appel à du shell + de l'AppleScript...
je trouve ça super launchd ;-) -- une bévue
pere.noel
Matt wrote:
oui oui, le premier arg disparaît c'est pour cela que j'en met un "dummy", comme il disparaît...
Jamais eu de cas semblables.
inquiétant alors... chez moi cet artefact répète ... -- une bévue
Matt <hfrarg@syrius.org.invalid> wrote:
oui oui, le premier arg disparaît c'est pour cela que j'en met un
"dummy", comme il disparaît...
Jamais eu de cas semblables.
inquiétant alors...
chez moi cet artefact répète ...
--
une bévue
oui oui, le premier arg disparaît c'est pour cela que j'en met un "dummy", comme il disparaît...
Jamais eu de cas semblables.
inquiétant alors... chez moi cet artefact répète ... -- une bévue
pere.noel
Matt wrote:
Ben un fichier qui disparaît et qui était dans un paquet obligatoire pour Mac OS X ça met la puce à l'oreille. D'autres fichiers ont peut-être subi le même sort tu ne crois pas ?
possible, j'ai téléchargé "launchd.plist.5.html" effectivement pour "ProgramArguments" il est bien spécifié "<array of strings>", c'est dommage, ils auraient pu prévoir un <dict/> nettement plus souple. enfin rien ne m'empèche de créer une plist en parallèle, plist dévouée aux args en hash... -- une bévue
Matt <hfrarg@syrius.org.invalid> wrote:
Ben un fichier qui disparaît et qui était dans un paquet obligatoire pour
Mac OS X ça met la puce à l'oreille.
D'autres fichiers ont peut-être subi le même sort tu ne crois pas ?
possible, j'ai téléchargé "launchd.plist.5.html" effectivement pour
"ProgramArguments" il est bien spécifié "<array of strings>", c'est
dommage, ils auraient pu prévoir un <dict/> nettement plus souple. enfin
rien ne m'empèche de créer une plist en parallèle, plist dévouée aux
args en hash...
--
une bévue
Ben un fichier qui disparaît et qui était dans un paquet obligatoire pour Mac OS X ça met la puce à l'oreille. D'autres fichiers ont peut-être subi le même sort tu ne crois pas ?
possible, j'ai téléchargé "launchd.plist.5.html" effectivement pour "ProgramArguments" il est bien spécifié "<array of strings>", c'est dommage, ils auraient pu prévoir un <dict/> nettement plus souple. enfin rien ne m'empèche de créer une plist en parallèle, plist dévouée aux args en hash... -- une bévue
