gaaaaaAab a écrit 1399 commentaires

c'est con, c'était ce qu'il y avait de plus simple.

C'est plus crado mais si tu peux supporter t'attendre 1 minutes, tu peux aussi coller un script en cron

man interfaces :


post-up command
Run command after bringing the interface up. If this command
fails then ifup aborts, refraining from marking the interface as
configured (even though it has really been configured), prints
an error message, and exits with status 0. This behavior may
change in the future.

A priori, il suffit que ta post-up command vérifie le SSID avant de déclencher ton script le cas échéant.

Ah oui, c'est parce que strace écrit tout sur stderr.
Du coup, plutôt que
strace svn ... > strace.out
fait plutôt
strace svn ... 2> strace.out

oui, strace est plus verbeux que moi ;)

En général, je pars de la fin des traces strace et je remonte en cherchant l'erreur. Je ne compte plus le nombre de fois ou ça m'a débrouillé des problèmes de droits ou de chemins différents de ce que je pensais.

Si la trace est un peu longue, les gens ont l'habitude de coller ça genre ici : pastebin.com/

strace pourrait donner des pistes sur ce qui échoue

oui, c'est un peu laconique comme commentaire :)

Il me semble que tu peux tout à fait écrire du soft proprio par dessus du code GPL, tant que le soft résultant n'est utilisé qu'en interne (cad qu'il n'y a pas de redistribution)

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