gaaaaaAab a écrit 1387 commentaires

mouais ... c'est dommage que de toutes les solutions proposées, tu t'arrêtes juste sur la plus crade :)

accessoirement, je ne suis pas du tout persuadé qu'attacher un strace à ton process sera moins couteux qu'une surveillance régulière :D

Autre solution, faire lancer ton process par un démon (qui connaitra donc le statut du fils en permanence), et prévoir un protocol de com avec ce démon pour que d'autres process puissent l'interroger sur l'état du fils en passant par des IPCs.
Par contre, en terme de dèv, c'est plus couteux que les autres solutions proposées ... (il faut p-e utiliser autre chose que du shell ?)

Evidemment, le postulat de départ est que le code de ce que tu veux lancer (le fils de ton premier shell) n'est pas sous ton contrôle, sinon, il "suffit" de multithreader le fils et de permettre à d'autres processus de s'enregistrer auprès de lui pour être notifié de la terminaison via des IPCs.

ça va être long comme méthode ça ...
Avec ps, tu peux récupérer la liste des utilisateurs pour lesquels un processus tourne.
Quelquechose comme : ps -eo user --noheader |sort -u
Attention, ça renvoie aussi les utilisateurs système (genre root, daemon, ...), il faut donc nettoyer cette liste pour ne garder que la liste des "vrais" utilisateurs.

Comme ton script sera lancé par root, tu peux aller regarder dans /etc/shadow pour distinguer les utilisateurs normaux des utilisateurs système qui n'ont en général pas le droit de se connecter, et dont le mot de passe sera donc * dans /etc/shadow.

Ensuite, tu n'auras plus qu'à faire le diff entre cette liste d'utilisateurs ayant des processus en cours et la liste des utilisateurs connectés. Pour chaque utilisateur non connecté, un simple su - <utilisateur&gt>; -c "kill -9 -1" devrait suffire.

donc 53

\(^.^)/

bon, je te plussoie, mais c'est parce que c'est Noël hein :D

grep -r motif dossier de depart | cut -d ':' -f1
peut se remplacer avantageusement par
grep -l motif dossier de depart
une autre sorte de UUOC tiens :)

en fait, c'est peut-être mieux d'aller voir ici :
http://david.acz.org/sdl.html

(pour info, la requête google, c'est makefile+skeleton+sdl)

pour une version 0.01 pré alpha, tu peux regarder là :
http://www.evl.uic.edu/arao/cs594/sdlglsl.html

Si tu veux un ./configure qui aille vérifier que SDL est bien présent avec les en-tête dans ta besoin dans la version qu'il te faut ... il faut jeter un oeil sur autoconf, automake (dans les autotools).
C'est peut-être un chouille plus compliqué mais comme je n'ai pas beaucoup pratiqué, je laisse d'autres élaborer.

pareil

Effectivement, c'était pas clair =)

Le SQL "pur" est très bien pour gérer des cardinalités de type 0,1, n (pour n quelconque).
Par contre, c'est pas du tout adapté quand on veut fixer des valeurs de n.

En SQL "pas pur" ;) faut voir ... quel SGBD utilises-tu ?

oula, ça fait beaucoup de questions :)

pour apporter mes 2 centimes, ce n'était pas une de tes questions, mais si tu fais du C++, c'est une quasi obligation d'utiliser le même compilateur pour compiler un programme et toutes les librairies C++ dont il dépend. Creuse du côté du mangling si tu veux approfondir la question.

Concernant le lien compilo/debugger, je n'ai pas une vision exhaustive, mais de ce que j'ai pu tester, le debugger est quand même vachement plus content quand il a à faire à du code généré par le compilo de la même suite. (chez nous, gdb a du mal sur code généré par aCC sur HP ou CC sur Solaris 9).

Qu'est-ce qui existe comme outil permettant de debugger du code parallélisé (openMP ou MPI) ?

heu ... un cerveau en parfait état de marche ? ;)

bon, je ne suis pas très content de mon retour chariot qui traîne, du coup, j'ai un truc un chouilla mieux à proposer :
echo wj------j----w------w--- | tr -cd '-' | wc -c

ouaip. quelque chose comme ça :
echo wj------j----w------w--- | sed -e 's/[^-]//g' | wc -c

en français, c'est remplacer tout ce qui n'est pas un tiret par rien, et compter ce qui reste.
mais attention, ma proposition compte le retour chariot en plus des -

Il y a peut-être un moyen de s'en sortir avec sed, mais je ne le connais pas. Sinon, ça peut se contourner en utilisant echo -n (plus généralement en travaillant avec des chaines de caractères sans retour chariot) ou en ôtant 1 du résultat

* Compte créé le samedi 25 octobre à 13:40
* Vu le samedi 25 octobre à 13:51
* le compte de cet utilisateur a été fermé

donc là, on est le samedi 25 Octobre et il est 14h30 ...
voila voila voila ...

Ah ouais, précision effectivement importante !
C'est con, c'était justement ça qui m'avait fait tripper ;-)

bien vu ! j'avais zappé "LOV"

boum, mon trollomètre a explosé dès ta première phrase :D

A ma gauche, les vieux langages comme le C, à ma droite .... les langages modernes + une bonne sémantique métier + une bonne architecture + une implémentation judicieuse ... c'est pas très équitable tout ça :-)

bon, là, je pense que tout le monde a compris que je fais du C toute la journée (et que j'aime ça en plus)

Revenons à nos moutons.

En réfléchissant sur les commentaires à l'occasion de ce sujet, je me rend compte que je ne les lis quasiment jamais. Plusieurs raisons à ça :
- quand le code est bien conçu et bien écrit, les commentaires sont quasi superflus,
- quand le code est mal écrit, les commentaires sont obsolètes ou hors sujet (bien que parfois hilarants).

Je n'ai besoin des commentaires que quand l'objectif poursuivi derrière un bloc de code n'est pas immédiatement compréhensible. Dans la pratique, c'est quand la logique métier vient imposer des contraintes arbitraires sur des éléments techniques ou quand l'architecture du soft fait que certaines écritures ésotériques sont privilégiées par rapport à une écriture plus classique.

Bref, c'est pas souvent.

Trust the source, Luke !

rhaaa lovely, je viens encore d'apprendre un truc sur sed !

Je vous défie de faire plus court :)

sed -ie 's/"//3g' input

Tu peux découper ton script en deux. Tout ce que tu fais en tant que root reste dans ton_script.sh. Tout ce que tu veux faire en tant que toto, tu le mets dans chemin/vers/toto.sh

yapuka (c) appeler toto.sh dans ton_script.sh :
su - toto -c chemin/vers/toto.sh

en tout cas, c'est comme ça qu'on fait chez nous :)

cherche sqlplusplus sur le grand 'Ternet. Une petite recompile de rien du tout, et t'as readline sur sqlplus.

Tout pareil. Et à ce moment là, je retourne sur la page d'accueil, pour revoir, et sous mes yeux émerveillés se dévoile la vraie puissance de l'hyperlien "Dépêches" dans le menu horizontal en haut. Comme qui dirait hourra !

Attention ! (si j'interprète bien tes commentaires précédents) comme ton postrotate a lieu après le rotate, le fichier qui t'intéresse n'est plus mon_fichier.txt mais mon_fichier.txt.1 !

il faut bien t'emmerder a couper au bon endroit, virer ce que tu veux pas

en même temps, y a tellement d'outils pour faire ça que c'est jamais vraiment une galère. cut et awk (éventuellement aidés de head ou tail) répondent à la majorité des besoins en la matière. Ensuite, des regex relativement simple permettent de régler la quasi totalité des problèmes restant à coup de sed et de grep. Il faut un peu de temps pour se familiariser à ces outils polyvalents, mais ensuite, tout coule de source
Ce que tu appelles inefficacité ne correspondrait-il pas plutôt à un certain manque d'aisance en la matière (ce qui, entendons nous bien, n'est absolument pas un reproche) ?

prier que la sortie ne change pas d'une langue a l'autre,

En te lisant, ma première réaction, c'était de me dire "mince, c'est vrai ça". Du coup, je me suis mis à chercher des exemples de commandes pour lesquelles l'internationalisation pourrait poser problème ... et en fait, je ne trouve pas ... A dire vrai, ce sont souvent les messages d'erreurs qui sont internationalisés, ce qui ne pose aucun problème dans un script.
Ah si ! j'ai trouvé un cas ou ça peut géner : pour les appels à la commande date dont le format dépend des locales, ce qui se contourne facilement en appliquant des formats de date explicites. Mais je n'en vois pas d'autres ... une idée ?

Par contre, ta remarque me rappelle quand j'avais dû scripter des appels aux commandes de type net en dos (ça devait être sur du NT4 à l'époque), et là, oui, la langue posait problème car les formats de retour des commandes n'étaient pas homogènes.

des methodes, qui elles ne changent pas
Tu connais mieux Powershell que moi. En tout cas, côté shell Unix, les formats de sortie des commandes standards ne changent pas beaucoup non plus. Il y a éventuellement des problèmes de compatibilité entre système Unix différents (genre du et df qui n'ont pas du tout la même tête entre Solaris/HP-UX et Linux), mais c'est un autre débat, et c'est relativement rare.

Disclaimer, je ne connais pas du tout Powershell. Cependant, a priori, il me semble que fonctionner avec des objets et des méthodes, ça demande autant de mémoire que de retenir les options des différentes commandes Unix. Je me trompe ?

--
gab

c'est un défi ? =)

parce qu'en tant qu'utilisateur de shell dans la vie de tous les jours, je veux bien des exemples d'énoncés ou le shell serait inefficace ...

c'est bien de me conseiller de pas faire des kill -9, mais pourquoi ?

Parce que les process bien éduqués meurent proprement au SIGTERM :)

oula ! je me rends compte que je divague un peu =)
Vu qu'apparement, c'est pour archiver tout ces trucs là, ça ne pose pas de problème si logrotate ne retrouve pas les motifs de nom des fichiers.
Du coup, le lancement en hourly et ton idée d'utiliser le postrotate me semble être une bonne solution.