gaaaaaAab a écrit 1393 commentaires

Tout pareil. Et à ce moment là, je retourne sur la page d'accueil, pour revoir, et sous mes yeux émerveillés se dévoile la vraie puissance de l'hyperlien "Dépêches" dans le menu horizontal en haut. Comme qui dirait hourra !

Attention ! (si j'interprète bien tes commentaires précédents) comme ton postrotate a lieu après le rotate, le fichier qui t'intéresse n'est plus mon_fichier.txt mais mon_fichier.txt.1 !

il faut bien t'emmerder a couper au bon endroit, virer ce que tu veux pas

en même temps, y a tellement d'outils pour faire ça que c'est jamais vraiment une galère. cut et awk (éventuellement aidés de head ou tail) répondent à la majorité des besoins en la matière. Ensuite, des regex relativement simple permettent de régler la quasi totalité des problèmes restant à coup de sed et de grep. Il faut un peu de temps pour se familiariser à ces outils polyvalents, mais ensuite, tout coule de source
Ce que tu appelles inefficacité ne correspondrait-il pas plutôt à un certain manque d'aisance en la matière (ce qui, entendons nous bien, n'est absolument pas un reproche) ?

prier que la sortie ne change pas d'une langue a l'autre,

En te lisant, ma première réaction, c'était de me dire "mince, c'est vrai ça". Du coup, je me suis mis à chercher des exemples de commandes pour lesquelles l'internationalisation pourrait poser problème ... et en fait, je ne trouve pas ... A dire vrai, ce sont souvent les messages d'erreurs qui sont internationalisés, ce qui ne pose aucun problème dans un script.
Ah si ! j'ai trouvé un cas ou ça peut géner : pour les appels à la commande date dont le format dépend des locales, ce qui se contourne facilement en appliquant des formats de date explicites. Mais je n'en vois pas d'autres ... une idée ?

Par contre, ta remarque me rappelle quand j'avais dû scripter des appels aux commandes de type net en dos (ça devait être sur du NT4 à l'époque), et là, oui, la langue posait problème car les formats de retour des commandes n'étaient pas homogènes.

des methodes, qui elles ne changent pas
Tu connais mieux Powershell que moi. En tout cas, côté shell Unix, les formats de sortie des commandes standards ne changent pas beaucoup non plus. Il y a éventuellement des problèmes de compatibilité entre système Unix différents (genre du et df qui n'ont pas du tout la même tête entre Solaris/HP-UX et Linux), mais c'est un autre débat, et c'est relativement rare.

Disclaimer, je ne connais pas du tout Powershell. Cependant, a priori, il me semble que fonctionner avec des objets et des méthodes, ça demande autant de mémoire que de retenir les options des différentes commandes Unix. Je me trompe ?

--
gab

c'est un défi ? =)

parce qu'en tant qu'utilisateur de shell dans la vie de tous les jours, je veux bien des exemples d'énoncés ou le shell serait inefficace ...

c'est bien de me conseiller de pas faire des kill -9, mais pourquoi ?

Parce que les process bien éduqués meurent proprement au SIGTERM :)

oula ! je me rends compte que je divague un peu =)
Vu qu'apparement, c'est pour archiver tout ces trucs là, ça ne pose pas de problème si logrotate ne retrouve pas les motifs de nom des fichiers.
Du coup, le lancement en hourly et ton idée d'utiliser le postrotate me semble être une bonne solution.

pour la fréquence d'exécution de logrotate, il suffit de changer la conf de ton cron pour qu'il soit lancé toutes les heures au lieu d'une seule fois par jour. Sur la plupart des distribs actuelles, ça revient à déplacer le script de logrotate de cron.daily à cron.hourly.

En ce qui concerne le renommage des fichiers de conf, le problème, c'est que logrotate tourne sur des fichier dont le nom respecte le motif <nom_du_fichier>.. Si tu changes le motif en <nom_du_fichier>., tu pourras conserver 24 heures de log max.
Si tu veux conserver sur plusieurs jours, ça t'oblige à rajouter le jour dans le motif de ton extension, mais du coup, ça sera à ta charge de changer le jour d'un fichier avant réécriture, parce que je ne pense que logrotate pourra le faire pour toi. Bref, ça veut dire rajouter la gestion du jour dans le pre rotate.

Désolé si c'est un peu décousu, je réfléchis en même temps que j'écris =)

bon, bref, en jouant juste avec post rotate, ça doit suffire pour gérer les logs sur 24, et en jouant sur pre/post rotate, ça doit pouvoir le faire sur plusieurs jours.

Une autre méthode un peu imprécise mais éventuellement valable si les écritures dans ce fichier ont une volumétrie constante, c'est de jouer sur la taille max des logs ... quoique ... ça ne répondra pas à la problèmatique de nommage des logs en fonction de l'heure ...

Retirer tous les capots des touches (hors chiffres et symboles) et les replacer aléatoirement.

Au début, on tapote n'importe quoi, mais ça force à regarder l'écran plutôt que le clavier. C'est assez vite efficace pour apprendre son clavier (ça avait du me prendre une grosse semaine d'utilisation intensive de backspace, mais après, c'était bon)
Le petit défaut, c'est que ça n'indique pas sur quelles touches il faut mettre quels doigts. Du coup, c'est p-e à compléter ensuite avec un soft genre gnu typist ou autre plus évolué.

ça, c'est pour apprendre la clavier, après, pour la rapidité, il suffit de faire quelques semaines d'irc je dirais ;)

Salut,

un petit exemple simpliste de ce que tu veux faire et des petits bouts des scripts montrant clairement là ou ça coince, ça le ferait bien, histoire qu'on ait pas à résoudre les problèmes que tu as déjà résolu ;-)

Est ce que vraiment faire une image de ce qui doit être affiché et l'envoyer via un socket sur un serveur qui lui va l'envoyer à la CG n'est pas un peu obsolète aujourd'hui ?

Naaaannn !
Ca permet de faire des chouettes export display pour faire tourner des applis distantes, éventuellement dans un tunnel ssh, sur ton serveur X local, et ça, c'est bien =)

quoi ? pas encore un seul J2EE Lead Architect dans tous ces beaux commentaires ?!

pour scripter des appels à des commandes interactives, en règle générale, je fais des here script. Mais avec vi, c'est pas gagné, parce qu'il râle si l'input est pas un terminal.

Est-ce que echo ne pourrait pas suffire dans ton cas ?

echo 'SHELL=/bin/sh
PATH=/usr/bin
DEFAULT=/home/essai/mail/ #repertoire pa defaut ou sont stockes les mails
MAILDIR=/home/essai/
LOGFILE=$MAILDIR/.procmail.log

INCLUDEDIR=/home/essai/.procmailrc
MAILCOPY=/home/essai/copymail/

:0c:
* ^From.*fai@hotmail.com
$MAILCOPY' > /home/test/.procmailrc


ah oui, désolé, je suis passé un peu vite sur le début de ton post. plus qu'un oeil d'ouvert à cette heure là '-)

On ne gère pas un Unix comme un Windows. Ce n'est pas un système jetable.

Pour le coup, c'est pas une histoire de "marque". Quelque soit l'os, un système compromis est un système plus que jetable, il est à jeter !

ce qui est bien, c'est que tu évites adroitement la caricature et la généralisation hative dans le second paragraphe de ton commentaire ...

et y a la clim' au boulot =)

ah bien vu ! le + m'avait échappé dans ton premier post. Une option de find que je connaissais pas encore.

pff ... si faut relire les man des commandes qu'on croit connaitre à chaque fois, on est pas arrivé ... =)

ça sent plutôt l'expérience je dirais. Quand l'objectif annoncé est un peu original, ça vaut le coup de creuser pour avoir une idée du vrai besoin. Souvent, ça a juste rien à voir :)

Ah ! nan ! je suis déçu ! D'habitude, j'apprécie tes réponses dans les forums.
Mais le problème de celle là, c'est que même si elle marche, QI81EPA n'aura pas appris grand chose ... on est à deux doigts de l'incantation et des passes magnétiques là quand même ... non ?

sinon, pour qu'un user puisse monter un file system, il faut qu'il soit déclaré dans /etc/fstab avec l'option user (man fstab, google, ...)

Il me semble que les démons de montage automatique trifouillent justement le /etc/fstab,

et encore autre possibilité avec xargs (mangez en)
find repertoire_de_base -name "*.toto" | xargs rm

et si tu sais que c'est des fichiers, tu peux aussi rajouter l'option -type f de find.

ouais, c'était pas bien signalisé, t'avais oublié la balise <humour> pour inhiber les réacs comme moi ;-)

je pensais que la plupart des gens penseraient comme toi.

ouaip ... c'est bien parce que je ne savais pas trop quelle interprétation de ton commentaire choisir parmi les différentes possibles que j'ai réagi pour que tu précises les choses.
j'aurais preque envie de faire un sondage sur linuxfr pour savoir qui avait compris quoi sur ce coup là ...

/me retourne dans sa grotte

Si je comprend bien ton besoin, grep -F ça devrait le faire.
man grep ;-)

si seulement ...
you must be new here :)

J'avais hésité à répondre mais voir le commentaire précédent noté à 7 ...

As-tu ne serait-ce qu'un début de source pour étayer un tant soit peu ce que tu dis ou c'est de la supposition gratuite ? parce qu'à moins que je n'ai mal lu, rien de tel dans les liens de la dépèche ...

oui, j'avais mis des guillemets :-)

J'ai hésité sur hétérogénéité, mais c'était pas ça que je voulais dire. La diversité des données, c'est bien. Merci pour ce bon mot ;-)