J'ai écris un script shell (test.sh), que j'exécute sans pb dans le
Terminal (chmod 744, puis ./test.sh). Est-il possible de lancer ce
script par un simple double-clic sur ce fichier, dans la GUI OS X
(10.1.5) ?
De la même façon (attention oreilles sensibles) que sur un PC on peut
double-cliquer sur un test.bat, ce qui lance l'interpréteur de commande
et exécute le .bat.
In article <1g7k68z.1i133oa1bplpssN%, (Laurent C) wrote:
Saïd wrote:
killall Terminal en fin de script.
C'est pas sympa pout les autres fenetres de Terminal. Il y a une option de config de Terminal qui permet de fermer une fenetre quand le programme qui s'y execute se termine.
Oui, ça marche quand tu fait exit en interactif, mais pas dans un script ?!?
En effet. Les fenêtres ouverts via un fichier .command sont réglées pour ne pas se refermer automatiquement, quelque soit les préférences du Terminal, car lorsque l'on ouvre toto.command, la commande executée est :
toto.command; exit
Pour ne refermer que la fenêtre de toto.command, on peut faire :
osascript -e 'tell application "Terminal" to close front window' &
Patrick -- Patrick Stadelmann
In article <1g7k68z.1i133oa1bplpssN%laurent.c@ouanadou.fr>,
laurent.c@ouanadou.fr (Laurent C) wrote:
Saïd <saidNo@spaMquatramaran.ens.france> wrote:
killall Terminal
en fin de script.
C'est pas sympa pout les autres fenetres de Terminal. Il y a une option de
config de Terminal qui permet de fermer une fenetre quand le programme qui
s'y execute se termine.
Oui, ça marche quand tu fait exit en interactif, mais pas dans un script
?!?
En effet. Les fenêtres ouverts via un fichier .command sont réglées pour
ne pas se refermer automatiquement, quelque soit les préférences du
Terminal, car lorsque l'on ouvre toto.command, la commande executée est :
toto.command; exit
Pour ne refermer que la fenêtre de toto.command, on peut faire :
osascript -e 'tell application "Terminal" to close front window' &
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1g7k68z.1i133oa1bplpssN%, (Laurent C) wrote:
Saïd wrote:
killall Terminal en fin de script.
C'est pas sympa pout les autres fenetres de Terminal. Il y a une option de config de Terminal qui permet de fermer une fenetre quand le programme qui s'y execute se termine.
Oui, ça marche quand tu fait exit en interactif, mais pas dans un script ?!?
En effet. Les fenêtres ouverts via un fichier .command sont réglées pour ne pas se refermer automatiquement, quelque soit les préférences du Terminal, car lorsque l'on ouvre toto.command, la commande executée est :
toto.command; exit
Pour ne refermer que la fenêtre de toto.command, on peut faire :
osascript -e 'tell application "Terminal" to close front window' &
Patrick -- Patrick Stadelmann
Saïd
Nicolas MICHEL :
Pour répondre à Saïd, effectivement killall fait un "kill -9" par défaut alors que osascript fait un "quit" genre commande finder. Tu peux aussi faire un killall -3.
Je voulais parler d'eventuels fenetres de Terminal qui serait aurait ete ouverte par l'utilisateur independemment du script, pas de la violence du kill en question. En faisant un kill sur l'application Terminal tu vas fermer toutes les fenetres, a moins que kill -3 ne soit interprete par le Terminal comme une demande de fermeture des fenetres dont la sous-application (celle qu'ils ont lance, en l'occurence le script) est terminee. Mais j'ai un doute.
Tiens un faute de traduction dans la config du Terminal a l'endroit ou l'en specifie ce qui doit se passer apres que le shell ait termine, on trouve:
"Quand le shell existe:" Qui doit etre une traduction de "When the shell exits:"
-- Saïd.
Nicolas MICHEL :
Pour répondre à Saïd, effectivement killall fait un "kill -9" par défaut
alors que osascript fait un "quit" genre commande finder. Tu peux aussi
faire un killall -3.
Je voulais parler d'eventuels fenetres de Terminal qui serait aurait ete
ouverte par l'utilisateur independemment du script, pas de la violence du
kill en question. En faisant un kill sur l'application Terminal tu vas
fermer toutes les fenetres, a moins que kill -3 ne soit interprete par le
Terminal comme une demande de fermeture des fenetres dont la
sous-application (celle qu'ils ont lance, en l'occurence le script) est
terminee. Mais j'ai un doute.
Tiens un faute de traduction dans la config du Terminal a l'endroit ou l'en
specifie ce qui doit se passer apres que le shell ait termine, on trouve:
"Quand le shell existe:"
Qui doit etre une traduction de
"When the shell exits:"
Pour répondre à Saïd, effectivement killall fait un "kill -9" par défaut alors que osascript fait un "quit" genre commande finder. Tu peux aussi faire un killall -3.
Je voulais parler d'eventuels fenetres de Terminal qui serait aurait ete ouverte par l'utilisateur independemment du script, pas de la violence du kill en question. En faisant un kill sur l'application Terminal tu vas fermer toutes les fenetres, a moins que kill -3 ne soit interprete par le Terminal comme une demande de fermeture des fenetres dont la sous-application (celle qu'ils ont lance, en l'occurence le script) est terminee. Mais j'ai un doute.
Tiens un faute de traduction dans la config du Terminal a l'endroit ou l'en specifie ce qui doit se passer apres que le shell ait termine, on trouve:
"Quand le shell existe:" Qui doit etre une traduction de "When the shell exits:"
-- Saïd.
pierre.ducrot
Nicolas MICHEL wrote:
Laurent C wrote:
Quelle simplicité ! Merci ! Question subsidiaire (j'abuse) : en double-cliquant, OS X lance le terminal, exécute le script + exit, mais ne quitte pas le Terminal. Est-il possible de forcer le Terminal to Quit ?
killall Terminal en fin de script.
ya aussi shutdown et reboot ou nuclear_reset...
-- Pierre
Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:
Laurent C <laurent.c@ouanadou.fr> wrote:
Quelle simplicité ! Merci !
Question subsidiaire (j'abuse) : en double-cliquant, OS X lance le
terminal, exécute le script + exit, mais ne quitte pas le Terminal.
Est-il possible de forcer le Terminal to Quit ?
Quelle simplicité ! Merci ! Question subsidiaire (j'abuse) : en double-cliquant, OS X lance le terminal, exécute le script + exit, mais ne quitte pas le Terminal. Est-il possible de forcer le Terminal to Quit ?
killall Terminal en fin de script.
ya aussi shutdown et reboot ou nuclear_reset...
-- Pierre
Jacky
Laurent C wrote:
les scripts, ça se fait avec /bin/sh bien sûr.
Ah bon ? Quand j'étais jeune j'utilisais exclusivement csh...
Ah, mais alors tu es encore trop jeune ;-)
--
"When we remember we are all mad, the mysteries of life disappear and life stands explained." -- Mark Twain
Laurent C wrote:
les scripts, ça se fait avec /bin/sh bien sûr.
Ah bon ? Quand j'étais jeune j'utilisais exclusivement csh...
Ah, mais alors tu es encore trop jeune ;-)
--
"When we remember we are all mad, the mysteries of life disappear and
life stands explained."
-- Mark Twain
Ah bon ? Quand j'étais jeune j'utilisais exclusivement csh...
Ah, mais alors tu es encore trop jeune ;-)
--
"When we remember we are all mad, the mysteries of life disappear and life stands explained." -- Mark Twain
Nicolas.MICHEL
Saïd wrote:
Je voulais parler d'eventuels fenetres de Terminal qui serait aurait ete ouverte par l'utilisateur independemment du script, pas de la violence du kill en question.
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit" et donc nuire au déroulement normal du script. Donc dans certains cas killall peut donc être quand-même intéressant, précisément parce qu'il est brutal.
Si tu n'as pas killall, l'équivalent avec kill peut être : kill $(ps -auxcww|grep Terminal|sed -e 's/ */ /g'|cut -f2 -d " ") (d'autres que moi auraient écrit la même chose avec plus de style, m'enfin on fait ce qu'on peut)
et enfin pour les script en csh: <http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/> perso, ça m'a convaincu. surtout pour des trucs genre: 2>>/var/log/monfichier.log
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Saïd <saidNo@spaMquatramaran.ens.france> wrote:
Je voulais parler d'eventuels fenetres de Terminal qui serait aurait ete
ouverte par l'utilisateur independemment du script, pas de la violence du
kill en question.
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit"
et donc nuire au déroulement normal du script. Donc dans certains cas
killall peut donc être quand-même intéressant, précisément parce qu'il
est brutal.
Si tu n'as pas killall, l'équivalent avec kill peut être :
kill $(ps -auxcww|grep Terminal|sed -e 's/ */ /g'|cut -f2 -d " ")
(d'autres que moi auraient écrit la même chose avec plus de style,
m'enfin on fait ce qu'on peut)
et enfin pour les script en csh:
<http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/>
perso, ça m'a convaincu. surtout pour des trucs genre:
2>>/var/log/monfichier.log
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Je voulais parler d'eventuels fenetres de Terminal qui serait aurait ete ouverte par l'utilisateur independemment du script, pas de la violence du kill en question.
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit" et donc nuire au déroulement normal du script. Donc dans certains cas killall peut donc être quand-même intéressant, précisément parce qu'il est brutal.
Si tu n'as pas killall, l'équivalent avec kill peut être : kill $(ps -auxcww|grep Terminal|sed -e 's/ */ /g'|cut -f2 -d " ") (d'autres que moi auraient écrit la même chose avec plus de style, m'enfin on fait ce qu'on peut)
et enfin pour les script en csh: <http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/> perso, ça m'a convaincu. surtout pour des trucs genre: 2>>/var/log/monfichier.log
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Patrick Stadelmann
In article <1g7lonm.4bat781w5wxvgN%, (Nicolas MICHEL) wrote:
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit" et donc nuire au déroulement normal du script.
Je ne vois pas pourquoi le déroulement "normal" d'un script nécessiterait de forcer le Terminal à quitter ! Si l'utilisateur a des tâches en court dans d'autres fenêtres, encore heureux qu'il puisse interrompre la fermeture !
Patrick -- Patrick Stadelmann
In article <1g7lonm.4bat781w5wxvgN%Nicolas.MICHEL@BonBon.net>,
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote:
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit"
et donc nuire au déroulement normal du script.
Je ne vois pas pourquoi le déroulement "normal" d'un script
nécessiterait de forcer le Terminal à quitter ! Si l'utilisateur a des
tâches en court dans d'autres fenêtres, encore heureux qu'il puisse
interrompre la fermeture !
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1g7lonm.4bat781w5wxvgN%, (Nicolas MICHEL) wrote:
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit" et donc nuire au déroulement normal du script.
Je ne vois pas pourquoi le déroulement "normal" d'un script nécessiterait de forcer le Terminal à quitter ! Si l'utilisateur a des tâches en court dans d'autres fenêtres, encore heureux qu'il puisse interrompre la fermeture !
Je suis pas très au clair, mais j'avais cru comprendre que les variables du shell peuvent varier suivant le contexte. Genre si c'est un shell interactif, shell de login, si le shell est lancé par un autre utilisateur... Sans parler des diférents shell. Il faudrait donc inclure le "echo $PATH" dans le script pour voir le résultat dans le contexte. Et tant qu'à faire, tu peux lancer le script en "mode débug" : sh -vx monscript ou inclure à la première ligne du script : #!/bin/sh -vx
Je suis pas très au clair, mais j'avais cru comprendre que les variables
du shell peuvent varier suivant le contexte. Genre si c'est un shell
interactif, shell de login, si le shell est lancé par un autre
utilisateur... Sans parler des diférents shell.
Il faudrait donc inclure le "echo $PATH" dans le script pour voir le
résultat dans le contexte. Et tant qu'à faire, tu peux lancer le script
en "mode débug" : sh -vx monscript ou inclure à la première ligne du
script :
#!/bin/sh -vx
Je suis pas très au clair, mais j'avais cru comprendre que les variables du shell peuvent varier suivant le contexte. Genre si c'est un shell interactif, shell de login, si le shell est lancé par un autre utilisateur... Sans parler des diférents shell. Il faudrait donc inclure le "echo $PATH" dans le script pour voir le résultat dans le contexte. Et tant qu'à faire, tu peux lancer le script en "mode débug" : sh -vx monscript ou inclure à la première ligne du script : #!/bin/sh -vx
-- scripteur amateur mais amateur de script
Saïd
Patrick Stadelmann :
In article <1g7lonm.4bat781w5wxvgN%, (Nicolas MICHEL) wrote:
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit" et donc nuire au déroulement normal du script.
Je ne vois pas pourquoi le déroulement "normal" d'un script nécessiterait de forcer le Terminal à quitter ! Si l'utilisateur a des tâches en court dans d'autres fenêtres, encore heureux qu'il puisse interrompre la fermeture !
C'est bien ce que j'essaye de dire, tuer Terminal n'est pas la bonne solution pour fermer la fenetre qui execute un script.
Peut-etre qu'on peut changer les parametres de la fenetre du script avec Property List Editor (fourni avec les outils de developpement) ou alors a la main pour que la fenetre se referme a la fin de la tache.
-- Saïd.
Patrick Stadelmann :
In article <1g7lonm.4bat781w5wxvgN%Nicolas.MICHEL@BonBon.net>,
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote:
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit"
et donc nuire au déroulement normal du script.
Je ne vois pas pourquoi le déroulement "normal" d'un script
nécessiterait de forcer le Terminal à quitter ! Si l'utilisateur a des
tâches en court dans d'autres fenêtres, encore heureux qu'il puisse
interrompre la fermeture !
C'est bien ce que j'essaye de dire, tuer Terminal n'est pas la bonne
solution pour fermer la fenetre qui execute un script.
Peut-etre qu'on peut changer les parametres de la fenetre du script avec
Property List Editor (fourni avec les outils de developpement) ou alors a la
main pour que la fenetre se referme a la fin de la tache.
In article <1g7lonm.4bat781w5wxvgN%, (Nicolas MICHEL) wrote:
Je soupçonne osascript de permettre à l'utilisateur d'annuler le "quit" et donc nuire au déroulement normal du script.
Je ne vois pas pourquoi le déroulement "normal" d'un script nécessiterait de forcer le Terminal à quitter ! Si l'utilisateur a des tâches en court dans d'autres fenêtres, encore heureux qu'il puisse interrompre la fermeture !
C'est bien ce que j'essaye de dire, tuer Terminal n'est pas la bonne solution pour fermer la fenetre qui execute un script.
Peut-etre qu'on peut changer les parametres de la fenetre du script avec Property List Editor (fourni avec les outils de developpement) ou alors a la main pour que la fenetre se referme a la fin de la tache.
-- Saïd.
Nicolas.MICHEL
Patrick Stadelmann wrote:
Je ne vois pas pourquoi le déroulement "normal" d'un script nécessiterait de forcer le Terminal à quitter !
C'est vrais que c'est improbable, mais c'est possible. Comme pour un disjoncteur : tu demandes pas à madame si elle a finit de se tirer son café quand il y a surtension : tu coupes. Pour un logoff à heure dite, genre c'est l'heure, on ferme, ou pour une update system nécessitant un reboot, par exemple. Si tu permet l'annulation, il y aura toujours quelques moutons noirs qui 3 semaines après n'auront pas obtempérés. Et suivant la politique de sécurité, ça peut ne pas être acceptable.
Un dictateur someil en chaque admin system, sauf chez moi : Je l'ai réveillé :->
Si l'utilisateur a des tâches en court dans d'autres fenêtres, encore heureux qu'il puisse interrompre la fermeture !
Tu es physicien, tu peux pas comprendre :-> Quel travail un utilisateur "normal" peut-il bien avoir en cours dans le terminal ? un mail dans pine, une session ssh sur un serveur, une rédaction de texte dans vi ? J'y crois pas une seconde :) J'admet qu'il y a un risque, mais il peut être préférable à une faille dans ton script. Et rien ne t'empêche d'avertir l'utilisateur en lui donnant un délais pour quitter, genre echo "on ferme" ; sleep 60 ; killall...
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Je ne vois pas pourquoi le déroulement "normal" d'un script
nécessiterait de forcer le Terminal à quitter !
C'est vrais que c'est improbable, mais c'est possible.
Comme pour un disjoncteur : tu demandes pas à madame si elle a finit de
se tirer son café quand il y a surtension : tu coupes.
Pour un logoff à heure dite, genre c'est l'heure, on ferme, ou pour une
update system nécessitant un reboot, par exemple. Si tu permet
l'annulation, il y aura toujours quelques moutons noirs qui 3 semaines
après n'auront pas obtempérés. Et suivant la politique de sécurité, ça
peut ne pas être acceptable.
Un dictateur someil en chaque admin system, sauf chez moi :
Je l'ai réveillé :->
Si l'utilisateur a des
tâches en court dans d'autres fenêtres, encore heureux qu'il puisse
interrompre la fermeture !
Tu es physicien, tu peux pas comprendre :->
Quel travail un utilisateur "normal" peut-il bien avoir en cours dans le
terminal ? un mail dans pine, une session ssh sur un serveur, une
rédaction de texte dans vi ? J'y crois pas une seconde :)
J'admet qu'il y a un risque, mais il peut être préférable à une faille
dans ton script. Et rien ne t'empêche d'avertir l'utilisateur en lui
donnant un délais pour quitter, genre
echo "on ferme" ; sleep 60 ; killall...
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Je ne vois pas pourquoi le déroulement "normal" d'un script nécessiterait de forcer le Terminal à quitter !
C'est vrais que c'est improbable, mais c'est possible. Comme pour un disjoncteur : tu demandes pas à madame si elle a finit de se tirer son café quand il y a surtension : tu coupes. Pour un logoff à heure dite, genre c'est l'heure, on ferme, ou pour une update system nécessitant un reboot, par exemple. Si tu permet l'annulation, il y aura toujours quelques moutons noirs qui 3 semaines après n'auront pas obtempérés. Et suivant la politique de sécurité, ça peut ne pas être acceptable.
Un dictateur someil en chaque admin system, sauf chez moi : Je l'ai réveillé :->
Si l'utilisateur a des tâches en court dans d'autres fenêtres, encore heureux qu'il puisse interrompre la fermeture !
Tu es physicien, tu peux pas comprendre :-> Quel travail un utilisateur "normal" peut-il bien avoir en cours dans le terminal ? un mail dans pine, une session ssh sur un serveur, une rédaction de texte dans vi ? J'y crois pas une seconde :) J'admet qu'il y a un risque, mais il peut être préférable à une faille dans ton script. Et rien ne t'empêche d'avertir l'utilisateur en lui donnant un délais pour quitter, genre echo "on ferme" ; sleep 60 ; killall...
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Saïd
Nicolas MICHEL :
Si l'utilisateur a des tâches en court dans d'autres fenêtres, encore heureux qu'il puisse interrompre la fermeture !
Tu es physicien, tu peux pas comprendre :-> Quel travail un utilisateur "normal" peut-il bien avoir en cours dans le terminal ? un mail dans pine, une session ssh sur un serveur, une rédaction de texte dans vi ? J'y crois pas une seconde :)
Une lecture de news sur slrn, t'y crois? ;-)
J'admet qu'il y a un risque, mais il peut être préférable à une faille dans ton script. Et rien ne t'empêche d'avertir l'utilisateur en lui donnant un délais pour quitter, genre echo "on ferme" ; sleep 60 ; killall...
Sans vouloir etre agresseif, continue comme ca et tu vas finir par etre contacte par microsoft pour developper du logiciel chez eux. ;-)
-- Saïd. (It's not a bug, it's a feature.)
Nicolas MICHEL :
Si l'utilisateur a des
tâches en court dans d'autres fenêtres, encore heureux qu'il puisse
interrompre la fermeture !
Tu es physicien, tu peux pas comprendre :->
Quel travail un utilisateur "normal" peut-il bien avoir en cours dans le
terminal ? un mail dans pine, une session ssh sur un serveur, une
rédaction de texte dans vi ? J'y crois pas une seconde :)
Une lecture de news sur slrn, t'y crois? ;-)
J'admet qu'il y a un risque, mais il peut être préférable à une faille
dans ton script. Et rien ne t'empêche d'avertir l'utilisateur en lui
donnant un délais pour quitter, genre
echo "on ferme" ; sleep 60 ; killall...
Sans vouloir etre agresseif, continue comme ca et tu vas finir par etre
contacte par microsoft pour developper du logiciel chez eux. ;-)
Si l'utilisateur a des tâches en court dans d'autres fenêtres, encore heureux qu'il puisse interrompre la fermeture !
Tu es physicien, tu peux pas comprendre :-> Quel travail un utilisateur "normal" peut-il bien avoir en cours dans le terminal ? un mail dans pine, une session ssh sur un serveur, une rédaction de texte dans vi ? J'y crois pas une seconde :)
Une lecture de news sur slrn, t'y crois? ;-)
J'admet qu'il y a un risque, mais il peut être préférable à une faille dans ton script. Et rien ne t'empêche d'avertir l'utilisateur en lui donnant un délais pour quitter, genre echo "on ferme" ; sleep 60 ; killall...
Sans vouloir etre agresseif, continue comme ca et tu vas finir par etre contacte par microsoft pour developper du logiciel chez eux. ;-)
