gaaaaaAab a écrit 1431 commentaires

le then après le if est bien là. Par contre, il en faut aussi un après le elif !

un soldat est un tueur salarié il ne faudrait tout de même pas l'oublier!

wow ! Vraiment trop gros là :D

mais maintenant, tout le monde a bien compris que Linus était souvent un gros troll ;-)

En utilisant simplement des print dans stdout, ça risque d'être assez velu =)
Regarde du côté du module curses, qui devrait te permettre de faire ce que tu veux (affichage multilines en console)
cf http://www.amk.ca/python/howto/curses/

Le module binascii propose pleins de fonctions sympas pour convertir des trucs dans tous les sens. De tête, je ne peux pas dire laquelle te conviendrait, mais un petit help (binascii) sera un bon point de départ ;)

faut laisser X tranquille maintenant monsieur :-)

Regarde du côté des préférences de ton Window Manager, à priori, il doit être configuré pour passer ton affichage en 1280x960 à chaque login.

man split, surtout l'option -l =)

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)