[Q] Lancement shellscript par double-clic

In article <1g7lvgy.syhyrh1np6f88N%Nicolas.MICHEL@BonBon.net>,
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote:

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 :)

Ca dépend de ta définition de normal : s'il s'agit d'un(e) secrétaire,
en effet il y a peu de chance. S'il s'agit d'un ingénieur ou d'un
chercheur, la probabilité est loin d'être nulle.

Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>

Saïd <saidNo@spaMquatramaran.ens.france> wrote:

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? ;-)

voilà Saïd qui se prends pour un utilisateur "normal" !
Désolé, mais on doit pas parler de la même chose.
Et non, je ne sous-estime pas les utilisateurs, pour le pire, il n'y a
pas meilleur, sans l'ombre d'un doute ils sont capables de tout. C'est
juste que dans ce cas de figure la probabilité dépends du nombre et du
type d'utilisateurs. Dans une entreprise "normale" genre une
administration, un cabinet de dentiste ou que sais-je, la probabilité
n'est pas la même que dans un milieu universitaire plein de linuxiens.

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. ;-)

C'est quoi ton rapport à l'informatique ? Tu fais du developpement ?
admin serveurs ? autre ? Tu es un linuxien qui a switché sur mac, non ?
(notes que ça ne me regardes pas, m'enfin :)

C'est une question de point de vue

Du point de vues de l'admin system qui gère un parc avec plein
d'utilisateurs, et qui doit obtennir un certain résultat, par exemple
une mise à jour de sécurité urgente parce que tu es en train de te faire
hacker sévère avec brutforce et tout et tout, et quand dans ce contexte
tu demandes 5x à un même utilisateur de redémarer sa machine, mais que
ledit utilisateur cliques cancel chaque fois, ne lit pas tes mails ni
les prompts que tu lui envoies, il y a un moment où tout en concidérant
que c'est pas sympa du tout, mais étant donné le nombre de machines à
mettre à jour avant que l'entreprise ne soit en sécurité, tu te dis
qu'un "shutdown -r now" est nécessaire. C'est du vécu.

En matière d'administration system, il vaut mieux ne pas laisser le
choix à l'utilisateur. Il faut expliquer ce qu'on fait et pourquoi, mais
pas soumettre le bon fonctionnement de l'entreprise à la volonté de
chaque : Sinon il y aura toujours 5% de gens qui te donneront plus de
travail que les 95 autres %.

Et je constates que si je fais bien ton travail, que j'expliques les
choses correctement et que le résultat fonctionne, même si parfois je
prends des mesures qui me valent une réputation de nazi sur fcomox, (ou
pire, de dev fin prêt à travailler pour M$) au final les utilisateurs
sont contents. Nettement plus que lorsque leur machine ne fonctionne pas
parce que tu leurs a laissé les droits admin et que l'un d'eux a testé
la mauvaise version de Nortong.
C'est bizarre, mais ils sont beaucoup plus agressifs quand ça marche pas
que quand tu leur refuses bonzybuddy. Vas comprendre... :)

--
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:

In article <1g7lvgy.syhyrh1np6f88N%Nicolas.MICHEL@BonBon.net>,
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote:

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 :)

Ca dépend de ta définition de normal : s'il s'agit d'un(e) secrétaire,
en effet il y a peu de chance. S'il s'agit d'un ingénieur ou d'un
chercheur, la probabilité est loin d'être nulle.

Vi, c'est clair.
Mais la question ne se pose en fait pas : si un admin écrit un petit
script pour gérer son parc, il est sensé connaitre les utilisateurs
auquels il a affaire, et il programmera en conséquence, selon le cas
qu'il fait du risque de perte de travail. J'ai jamais dit que kill était
la seule solution, je l'ai juste cité comme une possibilité.
C'est brutal, certes.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:

Et non, je ne sous-estime pas les utilisateurs, pour le pire, il n'y a
pas meilleur, sans l'ombre d'un doute ils sont capables de tout. C'est
juste que dans ce cas de figure la probabilité dépends du nombre et du
type d'utilisateurs. Dans une entreprise "normale" genre une
administration, un cabinet de dentiste ou que sais-je, la probabilité
n'est pas la même que dans un milieu universitaire plein de linuxiens.

Mais cette discussion m'énerve au plus haut point ! C'est
insupportable ! Je ne suis ni linuxien, ni en milieu universitaire, dans
une entreprise "normale" de plus de 500 personnes, et je me félicite que
l'administrateur système ne te ressemble pas ! Je ne pourrai pas
supporter ni le ton, ni le style, ni l'entrave !

En matière d'administration system, il vaut mieux ne pas laisser le
choix à l'utilisateur.

S'il n'y a autour de toi que des secrétaires qui seraient tout aussi
bien devant un simple terminal passif que devant un ordinateur
personnel, et que tout le monde soit content, c'est parfait. Les gens
sont souvent rassurés devant une autorité un peu ferme, sûre d'elle,
protectrice, tant qu'ils ne voient pas la privation de liberté. Ce sont
des aveugles informatiques de naissance. J'espère que tu as un droit de
regard sur leur formation continue et que vas pouvoir les empêcher de
s'informer de toutes les possibilités dont tu les prives. Ce serait
mieux pour toi, vois-tu.

Sinon, ils finiront par en avoir ras la casquette. Sois gentil de ne pas
généraliser ton entreprise normale ici. Ici, nous sommes tous des hors
normes, vois-tu, et certains en ont marre de prendre tes balles de golf
dans l'½il.
--
F. Jacquemin

In article <1g7m7o2.oq1yjt15re4gqN%Nicolas.MICHEL@BonBon.net>,
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote:

C'est brutal, certes.

Beaucoup moins que moi avec l'admin qui me ferra un coup pareil ;-))

Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>

François Jacquemin <fr_jacqu@nospam.club-internet.fr> wrote:

Mais cette discussion m'énerve au plus haut point ! C'est
insupportable ! Je ne suis ni linuxien, ni en milieu universitaire, dans
une entreprise "normale" de plus de 500 personnes, et je me félicite que
l'administrateur système ne te ressemble pas ! Je ne pourrai pas
supporter ni le ton, ni le style, ni l'entrave !

Je vois, une forte tête ! :>
MDR !

Dis moi François, quel est le niveau de service proposé par ton admin
system ?
Je suis curieux de voir à quoi resemble le monde dont tu me parles...
Tu as le mot de passe admin et tu peux gèrer ta machine comme tu
l'entends ?
Comment ça se passe si tu as besoins d'un nouveau programme, par
exemple. Tu peux le commander toi-même ? Ou on te l'achète et quelqu'un
vient te l'installer ?

--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas

Laurent C :

Bonjour,

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.

Merci.

Laurent.

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>

a remplacer par :

<key>ExecutionString</key>
<string>/usr/local/bini/script</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.

--
Saïd.

Saïd :
J'oubliais. J'ai trouvé la solution grace au livre "Mac OS X for Unix
Geeks". Comme quoi la lecture est la meilleur arme contre les admin
totalitaires (voir l'enfilade au dessus). ;-)

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' &

Et si le script met un certain temps a faire ce qu'il a a faire et que
pendant ce temps-la l'utilisateur change de fenetre Terminal pour vaquer a
ses propres occupations, c'est la fenetre de travail qui est fermee, non?

--
Saïd.

Saïd <saidNo@spaMquatramaran.ens.france> wrote:

Saïd :
J'oubliais. J'ai trouvé la solution grace au livre "Mac OS X for Unix
Geeks". Comme quoi la lecture est la meilleur arme contre les admin
totalitaires (voir l'enfilade au dessus). ;-)

Merci pour la solution... et la référence bibliographique qui a l'air
pas mal aussi.

Laurent.