gaaaaaAab a écrit 1393 commentaires

Oui ! C'est justement toute la différence entre la GPL et la LGPL.

cf le paragraphe non politique de http://www.gnu.org/licenses/why-not-lgpl.html :

The GNU Project has two principal licenses to use for libraries. One is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice of license makes a big difference: using the Lesser GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.

Pour préciser, ta remarque est valable pour les libs LGPL. Si tu links statiquement une lib LGPL, ton code doit être compatible GPL. Si tu links dynamiquement une lib LGPL, ton code peut être sous n'importe quelle licence.

Par contre, pour une lib purement GPL, tu n'as pas le choix. Quelque soit la technique de link utilisée (statique ou dynamique), ton logiciel doit être compatible GPL.

en même temps, vaut mieux dans ce sens là que dans l'autre ;-)

rhalala vivement l'interface graphique de tar !

--> []

nope, pas en utilisant le '+' à la fin de l'option -exec

cela dit, j'utilise systèmatiquement la version xargs, parce que :
- portabilité entre les unix (et oui, le find Solaris 9 est bien tout pourrave)
- pas envie d'apprendre des options spécifiques de find quand des commandes usuelles de shell, plus flexibles, permettent de faire la même chose.

Je militerais presque pour qu'on enlève des options de find ... pour revenir aux sources d'unix : faire une seule chose et le faire bien.

en fait, tout dépend du contexte dans lequel tu t'en sers.

Dans cas là, strace n'est pas utilisé pour tracer les appels systèmes, mais pour profiter d'un effet de bord : la détection de la fin du process. C'est typiquement du hack ;-)
Mais le fait de viser l'effet de bord, ça rend la solution trompeuse pour des lecteurs non avertis, et du coup, ça réduit la maintenabilité de la solution.
ça va bien pour un script fait chez soi, mais si c'est dans un contexte pro, il faut documenter ça, tout en sachant que de toute façon, personne lit la doc :D
C'est dans ce sens là que je trouve ça un peu crade.

bon, après, y a aussi des problèmes de portabilité sur d'autre *nix mais comme on est sur *linux*fr, on en parle pas (un troll se cache peut-être dans cette phrase ;-)

Après, c'est vrai que strace avec l'option -e'' (je vais pas faire mon malin, je la connaissais pas :), c'est probablement moins gourmand que le classique strace sans option qui te raconte la vie du noyau de la première lib dynamique pas trouvée 150 fois pendant le chargement du process aux 3 misérables appels systèmes dont ton code est "vraiment" responsable =)
Faudrait bencher de toute façon (comme pour toute les questions de perf)

sinon, le polling, c'est mal, mais ça peut être un compromis acceptable (comme d'utiliser strace ;-) là, y a que minitchoup qui sait vraiment ce qu'il veut faire ...

je précise, pour prévenir les interprétations erronées :
1/ les autres propositions de rb14 ne sont pas crades
2/ la solution que je propose est juste une vague ébauche pour signaler qu'il serait possible de mettre en place un méchanisme qui permettrait d'être notifié de la terminaison du processus fils d'un autre processus. Dans la pratique, ça vaut pas le coup. N'importe quelle solutions en shell, quitte à faire un peu de polling, sera sûrement plus adaptée !

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.