malgr=E8s plusieurs recherches sur google et dans les niouzes je
n'arrive pas =E0 trouver une solution =E0 mon pb :
l'id=E9e c'est de permettre =E0 mes utilisateurs d'utiliser vi pendant 10
min maximum et pas plus.
j'ai donc essay=E9 "d'enrober" l'appel dans un script mais je butte sur
quelques pbs. Notemment le fait que quand je passe vi en tache de fond
ca plante car il n'est plus alors reli=E9 a l'entr=E9e standard.
Voici mon script :
#!/bin/sh
TIMEOUT=3D600
vi $1&
p=3D$!
(sleep $TIMEOUT; [ `ps -ef | nawk '{print $2}' | grep -wc $p` -ne 0 ]
&& kill -9 $p) &
k=3D$!
wait $p 2> /dev/null
exit=3D$?
# Les codes de sortie sont 128+signal de sortie du processus qu'on
attend cf man
case $exit in
129)
echo '(timed out)' >&2
;;
*)
kill -kill $k 2> /dev/null
;;
esac
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
pierre.usenet
on m'a filé une soluce qui marche bien.
Si ca interresse du monde :
#!/bin/sh ( sleep 10 ; kill $$ ) & exec vi
On Oct 13, 2:36 pm, "" wrote:
Bonjour à tous,
malgrès plusieurs recherches sur google et dans les niouzes je n'arrive pas à trouver une solution à mon pb :
l'idée c'est de permettre à mes utilisateurs d'utiliser vi pendant 10 min maximum et pas plus.
j'ai donc essayé "d'enrober" l'appel dans un script mais je butte sur quelques pbs. Notemment le fait que quand je passe vi en tache de fond ca plante car il n'est plus alors relié a l'entrée standard.
Voici mon script :
#!/bin/sh TIMEOUT`0 vi $1& p=$! (sleep $TIMEOUT; [ `ps -ef | nawk '{print $2}' | grep -wc $p` -ne 0 ] && kill -9 $p) & k=$! wait $p 2> /dev/null exit=$? # Les codes de sortie sont 128+signal de sortie du processus qu'on attend cf man case $exit in 129) echo '(timed out)' >&2 ;; *) kill -kill $k 2> /dev/null ;; esac
Quelqu'un a-t-il une soluce ? Merci
on m'a filé une soluce qui marche bien.
Si ca interresse du monde :
#!/bin/sh
(
sleep 10 ; kill $$
) &
exec vi
On Oct 13, 2:36 pm, "pierre.use...@gmail.com" <pierre.use...@gmail.com>
wrote:
Bonjour à tous,
malgrès plusieurs recherches sur google et dans les niouzes je
n'arrive pas à trouver une solution à mon pb :
l'idée c'est de permettre à mes utilisateurs d'utiliser vi pendant 10
min maximum et pas plus.
j'ai donc essayé "d'enrober" l'appel dans un script mais je butte sur
quelques pbs. Notemment le fait que quand je passe vi en tache de fond
ca plante car il n'est plus alors relié a l'entrée standard.
Voici mon script :
#!/bin/sh
TIMEOUT=600
vi $1&
p=$!
(sleep $TIMEOUT; [ `ps -ef | nawk '{print $2}' | grep -wc $p` -ne 0 ]
&& kill -9 $p) &
k=$!
wait $p 2> /dev/null
exit=$?
# Les codes de sortie sont 128+signal de sortie du processus qu'on
attend cf man
case $exit in
129)
echo '(timed out)' >&2
;;
*)
kill -kill $k 2> /dev/null
;;
esac
malgrès plusieurs recherches sur google et dans les niouzes je n'arrive pas à trouver une solution à mon pb :
l'idée c'est de permettre à mes utilisateurs d'utiliser vi pendant 10 min maximum et pas plus.
j'ai donc essayé "d'enrober" l'appel dans un script mais je butte sur quelques pbs. Notemment le fait que quand je passe vi en tache de fond ca plante car il n'est plus alors relié a l'entrée standard.
Voici mon script :
#!/bin/sh TIMEOUT`0 vi $1& p=$! (sleep $TIMEOUT; [ `ps -ef | nawk '{print $2}' | grep -wc $p` -ne 0 ] && kill -9 $p) & k=$! wait $p 2> /dev/null exit=$? # Les codes de sortie sont 128+signal de sortie du processus qu'on attend cf man case $exit in 129) echo '(timed out)' >&2 ;; *) kill -kill $k 2> /dev/null ;; esac
Quelqu'un a-t-il une soluce ? Merci
moinsdespam
Dans ,
on m'a filé une soluce qui marche bien.
Si ca interresse du monde :
#!/bin/sh ( sleep 10 ; kill $$ ) & exec vi
Et c'est quoi l'intérêt de la manip par curiosité ?
-- Frédéric Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ; s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
Dans <1160745217.677572.84670@i3g2000cwc.googlegroups.com>,
on m'a filé une soluce qui marche bien.
Si ca interresse du monde :
#!/bin/sh
(
sleep 10 ; kill $$
) &
exec vi
Et c'est quoi l'intérêt de la manip par curiosité ?
--
Frédéric
Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un
ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ;
s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
Et c'est quoi l'intérêt de la manip par curiosité ?
-- Frédéric Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ; s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.É (et des BN))
Sébastien Monbrun aka TiChou
Dans le message <news:, *Frederic Dupas* tapota sur f.c.o.unix :
on m'a filé une soluce qui marche bien.
Si ca interresse du monde :
#!/bin/sh ( sleep 10 ; kill $$ ) & exec vi
Et c'est quoi l'intérêt de la manip par curiosité ?
D'une part.
Et d'autre part, quel moyen va être mis en place pour empêcher l'utilisateur à lancer directement /usr/bin/vi ?
-- Sébastien Monbrun aka TiChou
Dans le message <news:slrneiv7dn.b5m.moinsdespam@pafoo.net>,
*Frederic Dupas* tapota sur f.c.o.unix :
on m'a filé une soluce qui marche bien.
Si ca interresse du monde :
#!/bin/sh
(
sleep 10 ; kill $$
) &
exec vi
Et c'est quoi l'intérêt de la manip par curiosité ?
D'une part.
Et d'autre part, quel moyen va être mis en place pour empêcher l'utilisateur
à lancer directement /usr/bin/vi ?
Dans le message <news:, *Frederic Dupas* tapota sur f.c.o.unix :
on m'a filé une soluce qui marche bien.
Si ca interresse du monde :
#!/bin/sh ( sleep 10 ; kill $$ ) & exec vi
Et c'est quoi l'intérêt de la manip par curiosité ?
D'une part.
Et d'autre part, quel moyen va être mis en place pour empêcher l'utilisateur à lancer directement /usr/bin/vi ?
-- Sébastien Monbrun aka TiChou
Olivier Miakinen
#!/bin/sh ( sleep 10 ; kill $$ ) & exec vi
Et c'est quoi l'intérêt de la manip par curiosité ?
D'une part.
D'empêcher les gens de bosser ? Voir dix minutes de travail foutu en l'air parce j'aurais oublié de sauver avant 9 minutes et 59 secondes, ça me donnerait l'envie de trucider celui qui me fait ça.
Et d'autre part, quel moyen va être mis en place pour empêcher l'utilisateur à lancer directement /usr/bin/vi ?
Et enfin, la solution donnée tue le processus au bout de dix secondes au lieu de dix minutes. C'est bien, on a encore moins le temps de bosser.
Ah si, je sais : en réalité, c'est pour faire la promotion d'emacs en disant « vous voyez, vi c'est nul, il plante tout le temps ».
#!/bin/sh
(
sleep 10 ; kill $$
) &
exec vi
Et c'est quoi l'intérêt de la manip par curiosité ?
D'une part.
D'empêcher les gens de bosser ? Voir dix minutes de travail foutu en
l'air parce j'aurais oublié de sauver avant 9 minutes et 59 secondes, ça
me donnerait l'envie de trucider celui qui me fait ça.
Et d'autre part, quel moyen va être mis en place pour empêcher l'utilisateur
à lancer directement /usr/bin/vi ?
Et enfin, la solution donnée tue le processus au bout de dix secondes au
lieu de dix minutes. C'est bien, on a encore moins le temps de bosser.
Ah si, je sais : en réalité, c'est pour faire la promotion d'emacs en
disant « vous voyez, vi c'est nul, il plante tout le temps ».
Et c'est quoi l'intérêt de la manip par curiosité ?
D'une part.
D'empêcher les gens de bosser ? Voir dix minutes de travail foutu en l'air parce j'aurais oublié de sauver avant 9 minutes et 59 secondes, ça me donnerait l'envie de trucider celui qui me fait ça.
Et d'autre part, quel moyen va être mis en place pour empêcher l'utilisateur à lancer directement /usr/bin/vi ?
Et enfin, la solution donnée tue le processus au bout de dix secondes au lieu de dix minutes. C'est bien, on a encore moins le temps de bosser.
Ah si, je sais : en réalité, c'est pour faire la promotion d'emacs en disant « vous voyez, vi c'est nul, il plante tout le temps ».
pierre.usenet
On Oct 13, 5:05 pm, Sébastien Monbrun aka TiChou wrote:
Et c'est quoi l'intérêt de la manip par curiosité ?D'une part.
Ce serait asser complexe a expliquer complétement ici mais dans les grandes lignes voici la situation :
Certains utilisateurs d'un groupe A on la possibilitée de modifier certains maps NIS sur le systeme. Afin de gérer les accès concurents à ces maps j'ai enrobé vi dans un script qui lock les bases et les fichiers lorsqu'une personne édite ces fichiers.
D'autres utilisateurs d'un groupe B ont accès à une interface qui permet de modifier les mêmes maps. Une crontab dans permet de valider et compiler les modis apportées par les utilisateurs du groupe B.
Le pb est qu'il arrive que certains utilisateurs du groupe A oublient de quitter l'édition des maps. Ils bloquent alors tout le système (les utilisateurs du groupe A et du groupe B).
L'idée est donc de permettre l'édition des maps que pendant 10 minutes avant de refermer automatiquement et sans sauver les modifs en cas d'oubli.
Et d'autre part, quel moyen va être mis en place pour empêcher l'util isateur à lancer directement /usr/bin/vi ?
les utilisateurs lancent ces commandes par op.
On Oct 13, 5:05 pm, Sébastien Monbrun aka TiChou <gro.uohcit@uohcit>
wrote:
Et c'est quoi l'intérêt de la manip par curiosité ?D'une part.
Ce serait asser complexe a expliquer complétement ici mais dans les
grandes lignes voici la situation :
Certains utilisateurs d'un groupe A on la possibilitée de modifier
certains maps NIS sur le systeme.
Afin de gérer les accès concurents à ces maps j'ai enrobé vi dans
un script qui lock les bases et les fichiers lorsqu'une personne édite
ces fichiers.
D'autres utilisateurs d'un groupe B ont accès à une interface qui
permet de modifier les mêmes maps.
Une crontab dans permet de valider et compiler les modis apportées par
les utilisateurs du groupe B.
Le pb est qu'il arrive que certains utilisateurs du groupe A oublient
de quitter l'édition des maps. Ils bloquent alors tout le système
(les utilisateurs du groupe A et du groupe B).
L'idée est donc de permettre l'édition des maps que pendant 10
minutes avant de refermer automatiquement et sans sauver les modifs en
cas d'oubli.
Et d'autre part, quel moyen va être mis en place pour empêcher l'util isateur
à lancer directement /usr/bin/vi ?
On Oct 13, 5:05 pm, Sébastien Monbrun aka TiChou wrote:
Et c'est quoi l'intérêt de la manip par curiosité ?D'une part.
Ce serait asser complexe a expliquer complétement ici mais dans les grandes lignes voici la situation :
Certains utilisateurs d'un groupe A on la possibilitée de modifier certains maps NIS sur le systeme. Afin de gérer les accès concurents à ces maps j'ai enrobé vi dans un script qui lock les bases et les fichiers lorsqu'une personne édite ces fichiers.
D'autres utilisateurs d'un groupe B ont accès à une interface qui permet de modifier les mêmes maps. Une crontab dans permet de valider et compiler les modis apportées par les utilisateurs du groupe B.
Le pb est qu'il arrive que certains utilisateurs du groupe A oublient de quitter l'édition des maps. Ils bloquent alors tout le système (les utilisateurs du groupe A et du groupe B).
L'idée est donc de permettre l'édition des maps que pendant 10 minutes avant de refermer automatiquement et sans sauver les modifs en cas d'oubli.
Et d'autre part, quel moyen va être mis en place pour empêcher l'util isateur à lancer directement /usr/bin/vi ?
les utilisateurs lancent ces commandes par op.
pierre.usenet
On Oct 13, 7:17 pm, Olivier Miakinen <om+ wrote:
D'une part.D'empêcher les gens de bosser ? Voir dix minutes de travai l foutu en l'air parce j'aurais oublié de sauver avant 9 minutes et 59 secondes, ça
me donnerait l'envie de trucider celui qui me fait ça.
Celui qui met ca en place agit de la sorte car il sait qu'il y a des gens comme vous qui ne réfléchissent pas avant d'agir.
Ah si, je sais : en réalité, c'est pour faire la promotion d'emacs en disant « vous voyez, vi c'est nul, il plante tout le temps ».
Non c'est pour bosser ... pas pour glander sur les news (ce que permet emacs).
On Oct 13, 7:17 pm, Olivier Miakinen <om+n...@miakinen.net> wrote:
D'une part.D'empêcher les gens de bosser ? Voir dix minutes de travai l foutu en
l'air parce j'aurais oublié de sauver avant 9 minutes et 59 secondes, ça
me donnerait l'envie de trucider celui qui me fait ça.
Celui qui met ca en place agit de la sorte car il sait qu'il y a des
gens comme vous qui ne réfléchissent pas avant d'agir.
Ah si, je sais : en réalité, c'est pour faire la promotion d'emacs en
disant « vous voyez, vi c'est nul, il plante tout le temps ».
Non c'est pour bosser ... pas pour glander sur les news (ce que permet
emacs).
D'une part.D'empêcher les gens de bosser ? Voir dix minutes de travai l foutu en l'air parce j'aurais oublié de sauver avant 9 minutes et 59 secondes, ça
me donnerait l'envie de trucider celui qui me fait ça.
Celui qui met ca en place agit de la sorte car il sait qu'il y a des gens comme vous qui ne réfléchissent pas avant d'agir.
Ah si, je sais : en réalité, c'est pour faire la promotion d'emacs en disant « vous voyez, vi c'est nul, il plante tout le temps ».
Non c'est pour bosser ... pas pour glander sur les news (ce que permet emacs).
Nicolas George
"" wrote in message :
L'idée est donc de permettre l'édition des maps que pendant 10 minutes avant de refermer automatiquement et sans sauver les modifs en cas d'oubli.
Voilà, maintenant que tu expliques ton problème, on peut t'expliquer une solution : à l'ouverture, tu autorises ton système à forcer un verrou vieux de plus de T, à choisir (10 mn, tu dis) ; à la fermeture, tu vérifies si le verrou a été forcé : s'il est encore valable, tu valides la modification, s'il a été forcé, tu en informes l'utilisateur et tu lui proposes de relancer l'éditeur avec un merge de ses modifications et de celles qui ont eu lieu entre temps.
Et avant d'implémenter ça, tu te dis que ce n'est pas la peine de réinventer la roue, et tu passes les fichiers concernés sous CVS / Subversion / GIT / whatever.
"pierre.usenet@gmail.com" wrote in message
<1160843448.777604.305760@f16g2000cwb.googlegroups.com>:
L'idée est donc de permettre l'édition des maps que pendant 10
minutes avant de refermer automatiquement et sans sauver les modifs en
cas d'oubli.
Voilà, maintenant que tu expliques ton problème, on peut t'expliquer une
solution : à l'ouverture, tu autorises ton système à forcer un verrou vieux
de plus de T, à choisir (10 mn, tu dis) ; à la fermeture, tu vérifies si le
verrou a été forcé : s'il est encore valable, tu valides la modification,
s'il a été forcé, tu en informes l'utilisateur et tu lui proposes de
relancer l'éditeur avec un merge de ses modifications et de celles qui ont
eu lieu entre temps.
Et avant d'implémenter ça, tu te dis que ce n'est pas la peine de réinventer
la roue, et tu passes les fichiers concernés sous CVS / Subversion / GIT /
whatever.
L'idée est donc de permettre l'édition des maps que pendant 10 minutes avant de refermer automatiquement et sans sauver les modifs en cas d'oubli.
Voilà, maintenant que tu expliques ton problème, on peut t'expliquer une solution : à l'ouverture, tu autorises ton système à forcer un verrou vieux de plus de T, à choisir (10 mn, tu dis) ; à la fermeture, tu vérifies si le verrou a été forcé : s'il est encore valable, tu valides la modification, s'il a été forcé, tu en informes l'utilisateur et tu lui proposes de relancer l'éditeur avec un merge de ses modifications et de celles qui ont eu lieu entre temps.
Et avant d'implémenter ça, tu te dis que ce n'est pas la peine de réinventer la roue, et tu passes les fichiers concernés sous CVS / Subversion / GIT / whatever.
pierre.usenet
Nicolas George wrote:
Voilà, maintenant que tu expliques ton problème, on peut t'expliquer une solution : à l'ouverture, tu autorises ton système à forcer un verr ou vieux de plus de T, à choisir (10 mn, tu dis) ; à la fermeture, tu vérifi es si le verrou a été forcé : s'il est encore valable, tu valides la modific ation, s'il a été forcé, tu en informes l'utilisateur et tu lui proposes de relancer l'éditeur avec un merge de ses modifications et de celles qui ont eu lieu entre temps.
C'est ce qui est fait. Merci beaucoup pour votre aide.
Et avant d'implémenter ça, tu te dis que ce n'est pas la peine de r éinventer la roue, et tu passes les fichiers concernés sous CVS / Subversion / GI T / whatever.
Oui oui ... sauf que comme indiqué plus haut le système est plus complexe qu'il n'y parait : ces maps sont mises à jour par des outils web / interface texte / à la main / shells.
Il n'est pas possible de mettre en place cvs et co (chose à laquelle j'avais déjà pensé) ...
Nicolas George wrote:
Voilà, maintenant que tu expliques ton problème, on peut t'expliquer une
solution : à l'ouverture, tu autorises ton système à forcer un verr ou vieux
de plus de T, à choisir (10 mn, tu dis) ; à la fermeture, tu vérifi es si le
verrou a été forcé : s'il est encore valable, tu valides la modific ation,
s'il a été forcé, tu en informes l'utilisateur et tu lui proposes de
relancer l'éditeur avec un merge de ses modifications et de celles qui ont
eu lieu entre temps.
C'est ce qui est fait. Merci beaucoup pour votre aide.
Et avant d'implémenter ça, tu te dis que ce n'est pas la peine de r éinventer
la roue, et tu passes les fichiers concernés sous CVS / Subversion / GI T /
whatever.
Oui oui ... sauf que comme indiqué plus haut le système est plus
complexe qu'il n'y parait : ces maps sont mises à jour par des outils
web / interface texte / à la main / shells.
Il n'est pas possible de mettre en place cvs et co (chose à laquelle
j'avais déjà pensé) ...
Voilà, maintenant que tu expliques ton problème, on peut t'expliquer une solution : à l'ouverture, tu autorises ton système à forcer un verr ou vieux de plus de T, à choisir (10 mn, tu dis) ; à la fermeture, tu vérifi es si le verrou a été forcé : s'il est encore valable, tu valides la modific ation, s'il a été forcé, tu en informes l'utilisateur et tu lui proposes de relancer l'éditeur avec un merge de ses modifications et de celles qui ont eu lieu entre temps.
C'est ce qui est fait. Merci beaucoup pour votre aide.
Et avant d'implémenter ça, tu te dis que ce n'est pas la peine de r éinventer la roue, et tu passes les fichiers concernés sous CVS / Subversion / GI T / whatever.
Oui oui ... sauf que comme indiqué plus haut le système est plus complexe qu'il n'y parait : ces maps sont mises à jour par des outils web / interface texte / à la main / shells.
Il n'est pas possible de mettre en place cvs et co (chose à laquelle j'avais déjà pensé) ...
