gaaaaaAab a écrit 1431 commentaires

bizarre ... chez moi :
gabritou@gabritou $ touch fic1 fic2
gabritou@gabritou $ data=$(find . -name 'fic*')
gabritou@gabritou $ tail -f $data &
[2] 7180
==> ./fic1 <==

==> ./fic2 <==

gabritou@gabritou $ echo bla >> fic1
==> ./fic1 <==
bla
gabritou@gabritou $ echo bli >> fic2
==> ./fic2 <==
bli


de quelle façon il fonctionne pas ton script ?

tail sait "écouter" sur plusieurs fichiers en même temps :

tail -f /var/logs/access var/ldap/amAuthentication.access /var/apache/message /var/adm/messages &› /dev/console

ça devrait le faire. Dès qu'un truc bouge, tail remet le nom du fichier qui a été modifié

le côté récursif, c'est pas le problème. . find sert typiquement à ça

mais tu peux toujours faire un dos2unix sur ton fichier à modifier, le patcher, et faire un unix2dos sur le fichier résultant.

Sinon, tu peux tenter d'être un peu plus sélectif sur ta conversion des fins de ligne de ton fichier patch. En ne mettant que les lignes de "données" au format dos, ça marchera p-e. Juste une idée comme ça, je n'ai pas testé.

en même temps, si 50 personnes se mettent à te parler de ps en réponse à ton post, et que personne ne parle d'autre chose, c'est peut-être parce que ps va t'aider hein ;-)

voui, j'avais lu le man mais pas le manque de sommeil (trop chaud) fait que j'avais pas tilté et eu la flemme de creuser. Je plaide coupable :-)
A noter quand même que le -C est une option du ps GNU et donc pas portable sur HP et Solaris ...

le classique pour pas chopper le grep, c'est de rajouter une paire de [] dans le nom du process, genre :
ps <options de ps adapatées> | grep nom_du_proces[s]

l'explication, c'est que grep interprête [] quand il s'exécute (et le remplace par le bête caractère entre crochet), ce qui ne match plus la ligne du grep (qui elle contient toujours la paire de crochet)
C'est p-e plus clair en le testouillant soi même :-)

je plussoie, le C ne permet pas de construire une va_list au runtime de façon portable. Cf l'incontournable FAQ de comp.lang.c : http://c-faq.com/
notamment : http://c-faq.com/varargs/invvarargs.html

Si je ne dis pas de bétise, tu peux t'appuyer sur les simple cote pour extraire tes paramètres. Un truc comme ça peut-être ? :

echo "{value='truc';'machin' ; 'kkhjhj'}" | sed -e "s/[^']*'\([^']\+\)'*[^']*/\1\n/g"


Cette regex laisse une ligne vide à la fin. Ca doit donc pouvoir encore s'améliorer un chouilla ...

Tout est dans le titre. libcurl sait faire ça.
Je te laisse demander à google :-)

'tain, encore 15885 ans à tirer avant de pouvoir résister ...

--> [ ]

Je crois pas avoir déjà mis les pattes sur une Mandriva, mais sur les redhat like, je tenterais dans :
/ect/sysconfig/network-scripts/ifcfg-ra0

en reprenant tes commentaires, du coup, la réponse à la question c'est :
${10}

en relisant l'énoncé de départ, il faut adapter ma proposition pour gérer les parenthèses dans les données en entrée

je suis pas trop sûr que ça colle dans ton environnement (j'ai pas bien tout saisi), mais
avec un coup de sed, ça donne ça :

echo TRANSF EN PAR TRUC TOTO TITI TUTU | sed -e 's/\(\w\+\)\s\+\(\w\+\)\s\+/\1 \2\n/g'

y a matière à troller là :)

Le problème de fonctionner avec les versions localisées des softs, c'est que face à une erreur, 'on se retrouve souvent dans le cas :
"Je ne trouve pas grand chose sur les forums."

surtout pour les erreurs un peu "exotiques".

Je tire mon chapeau à Oracle là dessus. Ca doit être bien lourdingue de se cogner la maintenance d'une liste de code d'erreurs, mais faut reconnaitre que ça simplifie les recherches sur le net.

pour au cas ou, vérifie avec quelles options vim a été compilé
vim --version

si dans la réponse, y a un "-syntax", c'est que ton vim a été compilé sans le support de la coloration syntaxique.

tiens, je croyais que j'avais répondu sur ce forum, pis finalement non.

Rien à rajouter sur awk, tout a déjà été dit. Par contre, si tu as la main sur le programme qui crache le log, le mieux, ça serait quand même de le faire tout logguer sur une seule ligne.
Les logs multilignes, c'est très joli pour l'utilisateur, mais c'est inexploitable. Priez pour ne jamais avoir à parser le retour des commandes net * de windows ... (en tout cas, des nt 4)

s/tu fait/tu fais/

désolé

super HS mais comme la discussion m'intéresse :)

Ton argument me parait valable dans quelques contextes très précis :
- l'utilisateur n'a pas le niveau technique pour comprendre ce que fait l'alias (et il est perdu le jour ou l'alias ne fonctionne pas comme tu le dis dans ton exemple)
- plusieurs utilisateurs utilisent un même compte (si chacun met ses alias, c'est effectivement casse gueule)

Mais au départ, un alias, c'est juste un bête raccourci pour gagner du temps à la saisie. Ca ne dispense pas de savoir comment la commande "aliasé" fonctionne.

Dans le contexte du rm (je pense que l'option -i est relativement standard ;) , je ne pense pas que ce soit risqué de mettre un alias dessus pour les têtes en l'air. Cela dit, tu fait bien d'attirer plus généralement l'attention sur les soucis que peuvent poser les alias.

un peu HS, mais bon,

dans 99,99 % des cas, tu fais un rm et c'ést exactement ce que tu veux faire. Mettre en place un mécanisme de rm qui déplace dans un coin, c'est super lourdingue pour le nombre infime (quand on tape pas avec des moufles) de fois ou on fait un rm malencontreux. D'autant plus qu'il faut alors gérer le répertoire corbeille. Et ça ne résoud pas complètement le problème ... même comme ça, tu peux effacer un fichier que tu voulais restaurer ...

'fin bon, pour ma part, je reste au bon vieux rm. Quand je suis root, je fais un peu plus gaffe. Quand j'ai pleins de chemins de fichiers à effacer, je commence par faire un truc du genre
$ #rm fic1 dir1/fic1*.bla ....
je relis et je ne vire le # que quand ma ligne est finie (pas de * ou d'espace mal placé qui traine).
Autre solution, parfois, je commence par faire un ls de tout ce que je veux virer. Une fois le ls fait, je rappelle la ligne dans l'historique et je remplace le ls par rm.

au final, je suis 100% d'accord, "rm c'est rm"
pour les habitués des rm foireux, un bète alias rm='rm -i', ça peut déjà aider ;)

mes deux eurocents

ouaip, y a moyen de faire l'équivalent du system() en perl.

si tu as un interpréteur python sous la main:

$ python
Python 2.3.4 (#1, Feb 2 2005, 12:11:53)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> help (os)

lis ce qui concerne les functions exec*

Salut,

si la ligne de ta carte réseau n'apparait plus dans le dmesg, c'est que la carte n'est pas reconnu par le noyau, c'est à dire que le module qui la gère n'est pas présent.
le lsmod, c'est la bonne piste. Il faut que tu trouves le module qui gère ta carte (copain google) et que tu fasses ce qu'il faut pour qu'il soit présent dans ton 2.6 (re copain google. Ca repassera éventuellement par la recompile d'un module (donc la récupération des sources de ta version du noyau), l'installation au bon endroit et l'activation au boot)

dans le corps de la dépèche : <<Pour Paris, le rendez-vous est fixé Jeudi 30 Mars à 18h45 place de la Concorde>>

sur le premier lien : <<Le rendez-vous est à 18h30 sur l'esplanade en bas des marches de l'Opéra Bastille>>

alors chef, quand est-ce qu'on va ou ? :)

ben forcément, si tu dis pas tout ;)
Ca dépend ce que c'est qu'une visualisation. Si une simple sortie html suffit, pas besoin de s'embéter avec une api graphique.

au passage, je me rend compte que j'ai cité perl en premier, mais si perl peut le faire, python aussi : http://www.python.org/pypi/xlrd/0.5.2

pour savoir avec lequel de ces deux langages c'est le plus simple de faire des IHMs, je ne peux pas trop te répondre ... je préfère la bonne vieille ligne de commande.

p-e les lecteurs des forums python/perl sauraient plus ... ?