gaaaaaAab a écrit 1387 commentaires

oui hein :-)

sinon, pour l'exercice,
ls -t | tac

oui, ça n'a aucun intérêt, si ce n'est mettre un petit coup de projo sur la commande 'tac', injustement méconnue ;-)

le nombre max de répertoire par répertoire dépend du système de fichier.

Une petit recherche sur google avec les mots clefs "32000 directory ext2" et je tombe sur ça http://e2fsprogs.sourceforge.net/extensions-ext23/
extrait :
--
Another limitation imposed by the current inode field sizes is the use of a 16 bits for i_links_count, which limits the number of subdirectories that can be created in a single directory. The actual limit of 32,000 is smaller than what is possible with an unsigned 16-bit field, but even if the kernel were changed to allow 65,535 subdirectories, this would be too small for some users or applications.

s/t'aurais/t'aurait/

Je suis pas trop fan des variables globales mais bon ...
sinon, on peut aussi passer x en paramètre de titi et de toto
ou construire une classe bien choisie pour qu'un membre x soit facilement accessible par les méthodes de la classe (mais là, je manque un peu de contexte pour élaborer)

une petite remarque à Treepwood sur la forme : tu aurais pu continuer sur le fil http://linuxfr.org/forums/29/18466.html , on t'aurais répondu aussi :-)

sans faire d'exécution distante, il y a aussi
les here scripts, du genre :
$ telnet router << EOF
login
pasword
enable
copy running-config terminal
...
EOF
les here scripts, c'est bien quand on veut pas faire de la gestion d'erreur, sinon ça doit être un chouilla plus galère

ou sinon, y'a expect (google est ton ami parce que je suis pas expert expect :-)

mouais, avec un tail Solaris, c'est pas gagné ...
si tu peux installer/faire installer le tail de GNU, ça sera plus simple ...

globalement, si tu peux faire installer tous les utils GNU, tu galèreras moins ... ;-)

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é