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.
Et du coup chaque machine devient un cas particulier qui demande 4 fois plus de temps à gérer quand on doit ajouter un nouveau produit. Et du coup le service informatique devient moins performant, et les utilisateurs disent que c'est de sa faute, la preuve ils mettent plein de temps à venir. Ben oui, normal on est occupé à réinstaller l'os sur la machine de truc qui pour tapper sa frime a pris une carte graphique à la con, et les images disques qu'on distribue ne marchent pas sur sa machine, résultat on passe de 30 minutes à deux jours de boulot.
Pas du tout ! Ce n'est vraiment pas ce qui s'est passé ! Le service info qui était largement aux bottes de la direction n'a rien fait pour nos bécannes. On n'a jamais eu besoin du service info pour ces bécannes. AMHA, ils avaient d'autres chats à fouetter... On n'a même organisé un concours de vitesse entre un Apple IIe et une console DEC...
Résultat, HP est passé par là et a réussi à imposer ses HP9000 à la direction... Le service info n'éyait pas dans le coup.
-- yt
FiLH <filh@filh.org> wrote:
Et du coup chaque machine devient un cas particulier qui demande 4
fois plus de temps à gérer quand on doit ajouter un nouveau produit.
Et du coup le service informatique devient moins performant, et les
utilisateurs disent que c'est de sa faute, la preuve ils mettent plein
de temps à venir. Ben oui, normal on est occupé à réinstaller l'os sur
la machine de truc qui pour tapper sa frime a pris une carte graphique
à la con, et les images disques qu'on distribue ne marchent pas sur sa
machine, résultat on passe de 30 minutes à deux jours de boulot.
Pas du tout ! Ce n'est vraiment pas ce qui s'est passé ! Le service info
qui était largement aux bottes de la direction n'a rien fait pour nos
bécannes.
On n'a jamais eu besoin du service info pour ces bécannes. AMHA, ils
avaient d'autres chats à fouetter...
On n'a même organisé un concours de vitesse entre un Apple IIe et une
console DEC...
Résultat, HP est passé par là et a réussi à imposer ses HP9000 à la
direction... Le service info n'éyait pas dans le coup.
Et du coup chaque machine devient un cas particulier qui demande 4 fois plus de temps à gérer quand on doit ajouter un nouveau produit. Et du coup le service informatique devient moins performant, et les utilisateurs disent que c'est de sa faute, la preuve ils mettent plein de temps à venir. Ben oui, normal on est occupé à réinstaller l'os sur la machine de truc qui pour tapper sa frime a pris une carte graphique à la con, et les images disques qu'on distribue ne marchent pas sur sa machine, résultat on passe de 30 minutes à deux jours de boulot.
Pas du tout ! Ce n'est vraiment pas ce qui s'est passé ! Le service info qui était largement aux bottes de la direction n'a rien fait pour nos bécannes. On n'a jamais eu besoin du service info pour ces bécannes. AMHA, ils avaient d'autres chats à fouetter... On n'a même organisé un concours de vitesse entre un Apple IIe et une console DEC...
Résultat, HP est passé par là et a réussi à imposer ses HP9000 à la direction... Le service info n'éyait pas dans le coup.
-- yt
FiLH
(Yvon Thoraval) writes:
FiLH wrote:
Et du coup chaque machine devient un cas particulier qui demande 4 fois plus de temps à gérer quand on doit ajouter un nouveau produit. Et du coup le service informatique devient moins performant, et les utilisateurs disent que c'est de sa faute, la preuve ils mettent plein de temps à venir. Ben oui, normal on est occupé à réinstaller l'os sur la machine de truc qui pour tapper sa frime a pris une carte graphique à la con, et les images disques qu'on distribue ne marchent pas sur sa machine, résultat on passe de 30 minutes à deux jours de boulot.
Pas du tout ! Ce n'est vraiment pas ce qui s'est passé ! Le service info qui était largement aux bottes de la direction n'a rien fait pour nos bécannes.
Tu veux dire que vous faisiez tourner les progs DEC sur des Apple II ? Que les données étaient compatibles de l'un à l'autre ?
Le pb qu'on a actuellement c'est que les machines sont connectées et servent à travailler ENSEMBLE, que le service technique produit des bons de commandes qui sont traités par le service comptable, et que ces formats peuvent évoluer assez brutalement (si une loi change par exemple).
Ton exemple est daté. C'était vrai à l'époque de l'Apple II. J'ai aussi travaillé dans des boites avec les IBM du calcul d'un côté les Unisys de la gestion de l'autre.
Et pour faire passer la facturation du temps de calcul d'un système à l'autre on fait comment ?
FiLH.
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Et du coup chaque machine devient un cas particulier qui demande 4
fois plus de temps à gérer quand on doit ajouter un nouveau produit.
Et du coup le service informatique devient moins performant, et les
utilisateurs disent que c'est de sa faute, la preuve ils mettent plein
de temps à venir. Ben oui, normal on est occupé à réinstaller l'os sur
la machine de truc qui pour tapper sa frime a pris une carte graphique
à la con, et les images disques qu'on distribue ne marchent pas sur sa
machine, résultat on passe de 30 minutes à deux jours de boulot.
Pas du tout ! Ce n'est vraiment pas ce qui s'est passé ! Le service info
qui était largement aux bottes de la direction n'a rien fait pour nos
bécannes.
Tu veux dire que vous faisiez tourner les progs DEC sur des Apple II ?
Que les données étaient compatibles de l'un à l'autre ?
Le pb qu'on a actuellement c'est que les machines sont connectées et
servent à travailler ENSEMBLE, que le service technique produit des
bons de commandes qui sont traités par le service comptable, et que
ces formats peuvent évoluer assez brutalement (si une loi change par
exemple).
Ton exemple est daté. C'était vrai à l'époque de l'Apple II. J'ai
aussi travaillé dans des boites avec les IBM du calcul d'un côté les
Unisys de la gestion de l'autre.
Et pour faire passer la facturation du temps de calcul d'un système à
l'autre on fait comment ?
FiLH.
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Et du coup chaque machine devient un cas particulier qui demande 4 fois plus de temps à gérer quand on doit ajouter un nouveau produit. Et du coup le service informatique devient moins performant, et les utilisateurs disent que c'est de sa faute, la preuve ils mettent plein de temps à venir. Ben oui, normal on est occupé à réinstaller l'os sur la machine de truc qui pour tapper sa frime a pris une carte graphique à la con, et les images disques qu'on distribue ne marchent pas sur sa machine, résultat on passe de 30 minutes à deux jours de boulot.
Pas du tout ! Ce n'est vraiment pas ce qui s'est passé ! Le service info qui était largement aux bottes de la direction n'a rien fait pour nos bécannes.
Tu veux dire que vous faisiez tourner les progs DEC sur des Apple II ? Que les données étaient compatibles de l'un à l'autre ?
Le pb qu'on a actuellement c'est que les machines sont connectées et servent à travailler ENSEMBLE, que le service technique produit des bons de commandes qui sont traités par le service comptable, et que ces formats peuvent évoluer assez brutalement (si une loi change par exemple).
Ton exemple est daté. C'était vrai à l'époque de l'Apple II. J'ai aussi travaillé dans des boites avec les IBM du calcul d'un côté les Unisys de la gestion de l'autre.
Et pour faire passer la facturation du temps de calcul d'un système à l'autre on fait comment ?
FiLH.
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
laurent.pertois
Laurent C wrote:
%> which killall /usr/bin/killall
Donne rien chez moi. Because 0S X 10.1.5 ?
Oui, killall est apparu avec Mac OS X 10.2
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Laurent C <laurent.c@ouanadou.fr> wrote:
%> which killall
/usr/bin/killall
Donne rien chez moi. Because 0S X 10.1.5 ?
Oui, killall est apparu avec Mac OS X 10.2
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Saïd wrote:
"Quand le shell existe:" Qui doit etre une traduction de "When the shell exits:"
Bienvenue dans le monde joyeux des traductions hasardeuses de la 10.2...
Ami lecteur, toi aussi joue avec Mac OS X 10.2 et trouve les différences avec la version originale ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Saïd <saidNo@spaMquatramaran.ens.france> wrote:
"Quand le shell existe:"
Qui doit etre une traduction de
"When the shell exits:"
Bienvenue dans le monde joyeux des traductions hasardeuses de la 10.2...
Ami lecteur, toi aussi joue avec Mac OS X 10.2 et trouve les différences
avec la version originale ;-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
"Quand le shell existe:" Qui doit etre une traduction de "When the shell exits:"
Bienvenue dans le monde joyeux des traductions hasardeuses de la 10.2...
Ami lecteur, toi aussi joue avec Mac OS X 10.2 et trouve les différences avec la version originale ;-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas.MICHEL
FiLH wrote:
Et du coup chaque machine devient un cas particulier qui demande 4 fois plus de temps à gérer quand on doit ajouter un nouveau produit.
Non, d'expérience un parc de pc demande au moins le double de travail d'un parc de mac OS9 ou OS8 de même taille, pour peu que côté pc on fasse tout le tremblement des services/serveurs/loginscript... et que du côté des mac on laisse simplement les machines à l'état sauvage, avec les soft dispo pour tous dans un coin de serveur.
Parce que un mac s'installe par glisser-déposer du system et des appli, il démare sur le CD depuis des lustres et ne premet rien de compliqué. Parce que les utilisateurs étaient souvent capable de faire leures install eux-même et n'appelaient que une fois leur limite atteinte, laquelle reculait à chaque appel.
En revanche, c'était instable et les coruptions de données/extentions/partitions étaient monaie courante. Pas de backup, pas de montage auto, pas de sécurité d'accès aux données, pas de login unifié, ... C'était du mac quoi.
Ceci dit, pour les histoires de communication dans les parc hétérogènes, faudrait juste arrêter d'utiliser des moyens dépendants de la platteforme, ou alors passer à citrix. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
FiLH <filh@filh.org> wrote:
Et du coup chaque machine devient un cas particulier qui demande 4
fois plus de temps à gérer quand on doit ajouter un nouveau produit.
Non, d'expérience un parc de pc demande au moins le double de travail
d'un parc de mac OS9 ou OS8 de même taille, pour peu que côté pc on
fasse tout le tremblement des services/serveurs/loginscript... et que du
côté des mac on laisse simplement les machines à l'état sauvage, avec
les soft dispo pour tous dans un coin de serveur.
Parce que un mac s'installe par glisser-déposer du system et des appli,
il démare sur le CD depuis des lustres et ne premet rien de compliqué.
Parce que les utilisateurs étaient souvent capable de faire leures
install eux-même et n'appelaient que une fois leur limite atteinte,
laquelle reculait à chaque appel.
En revanche, c'était instable et les coruptions de
données/extentions/partitions étaient monaie courante. Pas de backup,
pas de montage auto, pas de sécurité d'accès aux données, pas de login
unifié, ... C'était du mac quoi.
Ceci dit, pour les histoires de communication dans les parc hétérogènes,
faudrait juste arrêter d'utiliser des moyens dépendants de la
platteforme, ou alors passer à citrix.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Et du coup chaque machine devient un cas particulier qui demande 4 fois plus de temps à gérer quand on doit ajouter un nouveau produit.
Non, d'expérience un parc de pc demande au moins le double de travail d'un parc de mac OS9 ou OS8 de même taille, pour peu que côté pc on fasse tout le tremblement des services/serveurs/loginscript... et que du côté des mac on laisse simplement les machines à l'état sauvage, avec les soft dispo pour tous dans un coin de serveur.
Parce que un mac s'installe par glisser-déposer du system et des appli, il démare sur le CD depuis des lustres et ne premet rien de compliqué. Parce que les utilisateurs étaient souvent capable de faire leures install eux-même et n'appelaient que une fois leur limite atteinte, laquelle reculait à chaque appel.
En revanche, c'était instable et les coruptions de données/extentions/partitions étaient monaie courante. Pas de backup, pas de montage auto, pas de sécurité d'accès aux données, pas de login unifié, ... C'était du mac quoi.
Ceci dit, pour les histoires de communication dans les parc hétérogènes, faudrait juste arrêter d'utiliser des moyens dépendants de la platteforme, ou alors passer à citrix. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Nicolas.MICHEL
Saïd wrote:
Bon, j'ai trouve une solution qui vaut ce qu'elle vaut.
Ouvrir un Terminal, puis aller dans les propriete pour faire en sorte que la fenetre se referme quand le shell termine. Puis Fichier->Sauvegarder
- mettre la sauvegarde la ou tu veux, c'est un fichier .term qui contient la configuration du Terminal. (on va dire que c'est ~/Desktop/script.term) - mettre le script a executer quelque part ou ca t'arrange (on va dire /usr/local/bini/script ) - le script doit se terminer par kill -9 $PPID (Au besoin duplique le script avec une version cliquable qui tue son pere (PPID = Parent Process ID) et une autre qui n'a pas d'instinct criminel et qui peut servir en ligne.
- editer le fichiet ~/Desktop/script.term avec un editeur de texte tout simple. - chercher la sequence: <key>ExecutionString</key> <string></string>
Voila. Apres un double-clique sur le fichier .term tu vas obtenir le resultat voulu. C'est quand meme chiant que le Terminal se sente toujours oblige de lancer un shell, meme si ExecutionString est mis.
J'ai rien compris. ça fait quoi au juste ?
Je suis passé il y a peu sur un des postes qui a un script.command se terminant par un killall Termianl et j'ai réalisé que depuis plus d'un an que ce script est installé sur un certain nombre de machines, j'ai jamais eu ne serais-ce qu'un remarque. Je sais pas si ça vaut le coup de les changer... C'était un de "mes" meilleurs utilisateur. :-)) -- 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:
Bon, j'ai trouve une solution qui vaut ce qu'elle vaut.
Ouvrir un Terminal, puis aller dans les propriete pour faire en sorte que
la fenetre se referme quand le shell termine.
Puis Fichier->Sauvegarder
- mettre la sauvegarde la ou tu veux, c'est un fichier .term qui contient
la configuration du Terminal. (on va dire que c'est ~/Desktop/script.term)
- mettre le script a executer quelque part ou ca t'arrange (on va dire
/usr/local/bini/script )
- le script doit se terminer par
kill -9 $PPID (Au besoin duplique le script avec une version cliquable
qui tue son pere (PPID = Parent Process ID) et une autre qui n'a pas
d'instinct criminel et qui peut servir en ligne.
- editer le fichiet ~/Desktop/script.term avec un editeur de texte tout
simple.
- chercher la sequence:
<key>ExecutionString</key>
<string></string>
Voila. Apres un double-clique sur le fichier .term tu vas obtenir le
resultat voulu. C'est quand meme chiant que le Terminal se sente toujours
oblige de lancer un shell, meme si ExecutionString est mis.
J'ai rien compris. ça fait quoi au juste ?
Je suis passé il y a peu sur un des postes qui a un script.command se
terminant par un killall Termianl et j'ai réalisé que depuis plus d'un
an que ce script est installé sur un certain nombre de machines, j'ai
jamais eu ne serais-ce qu'un remarque. Je sais pas si ça vaut le coup de
les changer... C'était un de "mes" meilleurs utilisateur. :-))
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Bon, j'ai trouve une solution qui vaut ce qu'elle vaut.
Ouvrir un Terminal, puis aller dans les propriete pour faire en sorte que la fenetre se referme quand le shell termine. Puis Fichier->Sauvegarder
- mettre la sauvegarde la ou tu veux, c'est un fichier .term qui contient la configuration du Terminal. (on va dire que c'est ~/Desktop/script.term) - mettre le script a executer quelque part ou ca t'arrange (on va dire /usr/local/bini/script ) - le script doit se terminer par kill -9 $PPID (Au besoin duplique le script avec une version cliquable qui tue son pere (PPID = Parent Process ID) et une autre qui n'a pas d'instinct criminel et qui peut servir en ligne.
- editer le fichiet ~/Desktop/script.term avec un editeur de texte tout simple. - chercher la sequence: <key>ExecutionString</key> <string></string>
Voila. Apres un double-clique sur le fichier .term tu vas obtenir le resultat voulu. C'est quand meme chiant que le Terminal se sente toujours oblige de lancer un shell, meme si ExecutionString est mis.
J'ai rien compris. ça fait quoi au juste ?
Je suis passé il y a peu sur un des postes qui a un script.command se terminant par un killall Termianl et j'ai réalisé que depuis plus d'un an que ce script est installé sur un certain nombre de machines, j'ai jamais eu ne serais-ce qu'un remarque. Je sais pas si ça vaut le coup de les changer... C'était un de "mes" meilleurs utilisateur. :-)) -- 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 :
J'ai rien compris. ça fait quoi au juste ?
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance. Ce qui repond a la question de depart: un script cliquable et qui fait le menage derriere lui.
-- Saïd.
Nicolas MICHEL :
J'ai rien compris. ça fait quoi au juste ?
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance.
Ce qui repond a la question de depart: un script cliquable et qui fait le
menage derriere lui.
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance. Ce qui repond a la question de depart: un script cliquable et qui fait le menage derriere lui.
-- Saïd.
FiLH
(Nicolas MICHEL) writes:
FiLH wrote:
Et du coup chaque machine devient un cas particulier qui demande 4 fois plus de temps à gérer quand on doit ajouter un nouveau produit.
Non, d'expérience un parc de pc demande au moins le double de travail d'un parc de mac OS9 ou OS8 de même taille, pour peu que côté pc on
Ah ben nous faut gérer les utilisatrices qui veulent passer sous PC parce que ça marche pas sous Mac. Ah bon et quoi ? Elle me montre une page web qui... ne marche pas non plus sous PC.
Mais comme ses collègues ont des PC...
En revanche, c'était instable et les coruptions de données/extentions/partitions étaient monaie courante. Pas de backup, pas de montage auto, pas de sécurité d'accès aux données, pas de login unifié, ... C'était du mac quoi.
On a des exigeances de sauvegarde sécurité accés données ! Mais ça le fait pas si mal.
Ceci dit, pour les histoires de communication dans les parc hétérogènes, faudrait juste arrêter d'utiliser des moyens dépendants de la platteforme,
Ça arrive doucement.
ou alors passer à citrix. Aussi.
Non le pb est d'avoir un parc homogène qu'on peut réinstaller rapidement. Là aussi ghost fait du progrés, mais les changements de pilotes ruinent le boulot.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Et du coup chaque machine devient un cas particulier qui demande 4
fois plus de temps à gérer quand on doit ajouter un nouveau produit.
Non, d'expérience un parc de pc demande au moins le double de travail
d'un parc de mac OS9 ou OS8 de même taille, pour peu que côté pc on
Ah ben nous faut gérer les utilisatrices qui veulent passer sous PC
parce que ça marche pas sous Mac.
Ah bon et quoi ?
Elle me montre une page web qui... ne marche pas non plus sous PC.
Mais comme ses collègues ont des PC...
En revanche, c'était instable et les coruptions de
données/extentions/partitions étaient monaie courante. Pas de backup,
pas de montage auto, pas de sécurité d'accès aux données, pas de login
unifié, ... C'était du mac quoi.
On a des exigeances de sauvegarde sécurité accés données !
Mais ça le fait pas si mal.
Ceci dit, pour les histoires de communication dans les parc hétérogènes,
faudrait juste arrêter d'utiliser des moyens dépendants de la
platteforme,
Ça arrive doucement.
ou alors passer à citrix.
Aussi.
Non le pb est d'avoir un parc homogène qu'on peut réinstaller
rapidement. Là aussi ghost fait du progrés, mais les changements de
pilotes ruinent le boulot.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Et du coup chaque machine devient un cas particulier qui demande 4 fois plus de temps à gérer quand on doit ajouter un nouveau produit.
Non, d'expérience un parc de pc demande au moins le double de travail d'un parc de mac OS9 ou OS8 de même taille, pour peu que côté pc on
Ah ben nous faut gérer les utilisatrices qui veulent passer sous PC parce que ça marche pas sous Mac. Ah bon et quoi ? Elle me montre une page web qui... ne marche pas non plus sous PC.
Mais comme ses collègues ont des PC...
En revanche, c'était instable et les coruptions de données/extentions/partitions étaient monaie courante. Pas de backup, pas de montage auto, pas de sécurité d'accès aux données, pas de login unifié, ... C'était du mac quoi.
On a des exigeances de sauvegarde sécurité accés données ! Mais ça le fait pas si mal.
Ceci dit, pour les histoires de communication dans les parc hétérogènes, faudrait juste arrêter d'utiliser des moyens dépendants de la platteforme,
Ça arrive doucement.
ou alors passer à citrix. Aussi.
Non le pb est d'avoir un parc homogène qu'on peut réinstaller rapidement. Là aussi ghost fait du progrés, mais les changements de pilotes ruinent le boulot.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Nicolas.MICHEL
Saïd wrote:
Nicolas MICHEL :
J'ai rien compris. ça fait quoi au juste ?
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance. Ce qui repond a la question de depart: un script cliquable et qui fait le menage derriere lui.
Euh, n'ayant toujours rien compris, je me suis résolu à suivre ton explication pas à pas et c'est très cool, j'ai appris plein de trucs :)
Ceci dit, il y a plus simple en tout cas sur ma 10.3 :
1) tu écris ton script normalement sans même le finir par "kill -9 $PPID" ni même par exit. le script n'a pas besoins d'avoir l'extention .command, mais il doit avoir les permissions d'exécution
2) dans le terminal, tu prends "windows settings" et dans l'onglet shell, when the shell exits "close the window"
3) dans le terminal encore, menu file/save tu coches la case "execute this command", tu entre le chemin de ton script et tu décoches "execute command in a shell", puis save.
Optionnellement tu met un titre explicite à ta fenêtre de terminal et tu désignes une image de fond comprenant le logo de ta société et un petit mot pour casser l'aspect rébarbatif du shell.
Bon, ça ne quite pas le terminal, il y aura toujours ce carré noir et terrifiant dans le doc pour les neuneu, mais les powerusers seront respectés dans leur geekitude intrinsèque :) -- 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:
Nicolas MICHEL :
J'ai rien compris. ça fait quoi au juste ?
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance.
Ce qui repond a la question de depart: un script cliquable et qui fait le
menage derriere lui.
Euh, n'ayant toujours rien compris, je me suis résolu à suivre ton
explication pas à pas et c'est très cool, j'ai appris plein de trucs :)
Ceci dit, il y a plus simple en tout cas sur ma 10.3 :
1) tu écris ton script normalement sans même le finir par "kill -9
$PPID" ni même par exit.
le script n'a pas besoins d'avoir l'extention .command, mais il doit
avoir les permissions d'exécution
2) dans le terminal, tu prends "windows settings"
et dans l'onglet shell, when the shell exits "close the window"
3) dans le terminal encore, menu file/save tu coches la case "execute
this command", tu entre le chemin de ton script et tu décoches "execute
command in a shell", puis save.
Optionnellement tu met un titre explicite à ta fenêtre de terminal et tu
désignes une image de fond comprenant le logo de ta société et un petit
mot pour casser l'aspect rébarbatif du shell.
Bon, ça ne quite pas le terminal, il y aura toujours ce carré noir et
terrifiant dans le doc pour les neuneu, mais les powerusers seront
respectés dans leur geekitude intrinsèque :)
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance. Ce qui repond a la question de depart: un script cliquable et qui fait le menage derriere lui.
Euh, n'ayant toujours rien compris, je me suis résolu à suivre ton explication pas à pas et c'est très cool, j'ai appris plein de trucs :)
Ceci dit, il y a plus simple en tout cas sur ma 10.3 :
1) tu écris ton script normalement sans même le finir par "kill -9 $PPID" ni même par exit. le script n'a pas besoins d'avoir l'extention .command, mais il doit avoir les permissions d'exécution
2) dans le terminal, tu prends "windows settings" et dans l'onglet shell, when the shell exits "close the window"
3) dans le terminal encore, menu file/save tu coches la case "execute this command", tu entre le chemin de ton script et tu décoches "execute command in a shell", puis save.
Optionnellement tu met un titre explicite à ta fenêtre de terminal et tu désignes une image de fond comprenant le logo de ta société et un petit mot pour casser l'aspect rébarbatif du shell.
Bon, ça ne quite pas le terminal, il y aura toujours ce carré noir et terrifiant dans le doc pour les neuneu, mais les powerusers seront respectés dans leur geekitude intrinsèque :) -- 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 :
Saïd wrote:
Nicolas MICHEL :
J'ai rien compris. ça fait quoi au juste ?
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance. Ce qui repond a la question de depart: un script cliquable et qui fait le menage derriere lui.
Euh, n'ayant toujours rien compris, je me suis résolu à suivre ton explication pas à pas et c'est très cool, j'ai appris plein de trucs :)
Ceci dit, il y a plus simple en tout cas sur ma 10.3 :
1) tu écris ton script normalement sans même le finir par "kill -9 $PPID" ni même par exit. le script n'a pas besoins d'avoir l'extention .command, mais il doit avoir les permissions d'exécution
2) dans le terminal, tu prends "windows settings" et dans l'onglet shell, when the shell exits "close the window"
3) dans le terminal encore, menu file/save tu coches la case "execute this command", tu entre le chemin de ton script et tu décoches "execute command in a shell", puis save.
C'est exactement ce que je fais. Au kill -9 $PPID pres, ce qui fait la fenetre ne se referme pas.
Optionnellement tu met un titre explicite à ta fenêtre de terminal et tu désignes une image de fond comprenant le logo de ta société et un petit mot pour casser l'aspect rébarbatif du shell.
Bon, ça ne quite pas le terminal, il y aura toujours ce carré noir et terrifiant dans le doc pour les neuneu, mais les powerusers seront respectés dans leur geekitude intrinsèque :)
Et t'es paye pour etre admin sys?
-- Saïd.
Nicolas MICHEL :
Saïd <saidNo@spaMquatramaran.ens.france> wrote:
Nicolas MICHEL :
J'ai rien compris. ça fait quoi au juste ?
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance.
Ce qui repond a la question de depart: un script cliquable et qui fait le
menage derriere lui.
Euh, n'ayant toujours rien compris, je me suis résolu à suivre ton
explication pas à pas et c'est très cool, j'ai appris plein de trucs :)
Ceci dit, il y a plus simple en tout cas sur ma 10.3 :
1) tu écris ton script normalement sans même le finir par "kill -9
$PPID" ni même par exit.
le script n'a pas besoins d'avoir l'extention .command, mais il doit
avoir les permissions d'exécution
2) dans le terminal, tu prends "windows settings"
et dans l'onglet shell, when the shell exits "close the window"
3) dans le terminal encore, menu file/save tu coches la case "execute
this command", tu entre le chemin de ton script et tu décoches "execute
command in a shell", puis save.
C'est exactement ce que je fais. Au kill -9 $PPID pres, ce qui fait la
fenetre ne se referme pas.
Optionnellement tu met un titre explicite à ta fenêtre de terminal et tu
désignes une image de fond comprenant le logo de ta société et un petit
mot pour casser l'aspect rébarbatif du shell.
Bon, ça ne quite pas le terminal, il y aura toujours ce carré noir et
terrifiant dans le doc pour les neuneu, mais les powerusers seront
respectés dans leur geekitude intrinsèque :)
Ca ne ferme que la fenetre de terminal dans laquelle le script s'est lance. Ce qui repond a la question de depart: un script cliquable et qui fait le menage derriere lui.
Euh, n'ayant toujours rien compris, je me suis résolu à suivre ton explication pas à pas et c'est très cool, j'ai appris plein de trucs :)
Ceci dit, il y a plus simple en tout cas sur ma 10.3 :
1) tu écris ton script normalement sans même le finir par "kill -9 $PPID" ni même par exit. le script n'a pas besoins d'avoir l'extention .command, mais il doit avoir les permissions d'exécution
2) dans le terminal, tu prends "windows settings" et dans l'onglet shell, when the shell exits "close the window"
3) dans le terminal encore, menu file/save tu coches la case "execute this command", tu entre le chemin de ton script et tu décoches "execute command in a shell", puis save.
C'est exactement ce que je fais. Au kill -9 $PPID pres, ce qui fait la fenetre ne se referme pas.
Optionnellement tu met un titre explicite à ta fenêtre de terminal et tu désignes une image de fond comprenant le logo de ta société et un petit mot pour casser l'aspect rébarbatif du shell.
Bon, ça ne quite pas le terminal, il y aura toujours ce carré noir et terrifiant dans le doc pour les neuneu, mais les powerusers seront respectés dans leur geekitude intrinsèque :)
