totof2000 a écrit 9656 commentaires

Je pense avoir compris. As tu mis des " " dans l'expression

$0= "ligne modifiee"

?

C'est sous Linux ou un autre OS?

Peux-tu me faire un copier/coller de ton bout de code awk?

Par contre je comprends pas pourquoi je perderai 24h de sauvegarde si mes sauvegardes foires?

Supposition: un jour, tu execute le find -mtime -1 | <commande_sauvegarde>. Pour une raison quelconque, ta commande de sauvegarde échoue, mais tu ne t'en rends pas compte. Le lendemain ta sauvegarde s'exécute de nouveau, mais elle ne prendra en compte que les modifications de la veille .... C'est pas forcément gênant, dans la mesure ou tu effectues une sauvegarde complête toutes les semaines, mais il faut seulement le savoir ...

pour info, toutes les versions de sed n'acceptent pas le -i (seul gnu sed à ma connaissance l'accepte). Attention si le script doit être portable ...

Ben si ... tu travaille dans un fichier temporaire, et à la fin tu le copie sur ton fichier d'origine ... ... Mais tu veux faire quoi plus précisément ?

je viens de me rendre compte que si un fichier est créé entre le début du "find" et la fin de celui-ci, il sera perdu.

Donc un truc du genre "touch temoin.tmp && find -newer fichier_temoin | <commande_sauvegarde> && mv temoin.tmp fichier_temoin " sera mieux.

problème: si la sauvegarde de la veille a foiré, tu perds des données.

En fait, le comportement de "echo" est différent entre les divers Unix/shell. Si on veut développer des scripts portables, il vaut mieux utiliser printf.

man find te donnera des infos.

Entre autre tu as l'option -mtime qui te permet de lister des fichiers en fonction de leur date de dernière modification, ou l'option -newer qui te permet de lister les fichiers plus récents que le fichier passé en paramètre.

Donc, un truc du genre "find . -mtime +1 | <commande de sauvegarde> te sauvera tous les fichiers créés depuis la veille.

L'inconvénient de cette méthode: si un jour ta sauvegarde foire, tu perds une journée. Personnellement je préfererai un truc du genre:

find . -newer fichier_temoin | <commande_de_sauvegarde> && touch fichier_temoin

GRRRR! Je recommence :

D'abord, avant toute modification, il te faut sauvegarder le fichier d'origine:

cp ancien_fichier ancien_fichier.sav

Ensuite:

awk ' {

(if $0 ~ "expression_recherchee") {

$0=ligne_modifiee

}

print $0

} ' ancien_fichier >nouveau_fichier.tmp

et enfin:

cp nouveau_fichier.tmp ancien_fichier

D'abord, avant toute modification, il te faut sauvegarder le fichier d'origine: cp ancien_fichier ancien_fichier.sav Ensuite: awk ' { (if $0 ~ "expression_recherchee") { $0=ligne_modifiee } print $0 } ' ancien_fichier >nouveau_fichier.tmp et enfin: cp nouveau_fichier.tmp ancien_fichier.

Autant pour moi,
C'est "au temps pour moi".

bref ca arrange bien le gouvernement que la CNILL soit incapable de remplir sa mission

J'irais même jusqu'à dire que le gouvernement a délibérément empêché la CNIL de remplir sa mission (gel de crédits) afin de faire passer en silence un certain nombre de lois .... Bref la CNIL est devenu une commision qui dans les faits ne sert à rien.

En conclusion, il faut bien reconnaître que NetBSD est le plus confidentiel des trois BSD "majeurs". Son créneau de la disponibilité multi-plateforme n'est pas très porteur (Linux est encore plus polyvalent) et l'accent récent mis sur la sécurité est eclipsé par l'aura d'OpenBSD. Pourtant, en dépit de la défection spectaculaire et des critiques acerbes d'un des fondateurs du projet on peut constater que NetBSD continue à avancer... doucement !

Trouve moi une distribution linux qui s'installe sur autant de plate formes que NetBSD, et on en reparle...

Sinon, il paraitrait que MacosX prend bien plus de parties de NetBSD que de FreeBSD ....

La nouveauté principale de cette version 3.1 est le support de la technologie de virtualisation Xen3 en DomU.

Netbsd peut tourner en Dom0 depuis NetBSD 3.0 au moins .... Par contre la nouveauté il me semble est le support de Xen3 (Dom0 et DomU).

Reiser5 bien sur ....

On l'oublie celui-là?

C'est la nouvelle mesure de protection des CD et graveur. Si tu as de la musique ou de la vidéo sur ta machine, le graveur refuse de reconnaitre les CD vierges.

Pour l'embarqué, ilm me semble que les processeurs ARM consomment moins que les x86. Quelqu'un pour confirmer/infirmer?

Surtout que la plupart des crétins qui jettent leur papier, mégot ou tout autre truc du genre paye, et me fait payer pour leurs conneries. ...

Pffff! je sais pas ce qui s'est passé hier, mais j'avais pas les idées res claires. 1an et 1 mois c'est exact. C'est effectivement pas mal.

..ité sort de la bouche des ...

Si je compte bien ca fait 4 ans de maintenance pour une distribution maintenue par des benevoles moi je trouve cela pas mal.

Relis la phrase du post auquel tu répond et recommence. Je t'aide:


> pas une distribution pour entreprise. Woody est resté maintenu moins d'un an après la sortie de Sarge . Sans commentaire ...

tu répond:

Ah ca c'est sûr effectivement:
sortie de la debian woody: 19/07/2002
sortie de la debian sarge: 6/06/2005
fin de la maintenance woody:30/06/2006

Si je compte bien ca fait 4 ans de maintenance pour une distribution maintenue par des benevoles moi je trouve cela pas mal.

ca fait bien moins d'un an de maintenance apres la sortie de Sarge (de 6/06/2006 a 30/06/2006 ça fait bien 1 mois).

remplace le "AR*" par /truc/machin/spool/AR ca devrait fonctionner. Sinon cd /truc/machin/spool && [ -f AR* ] && ls -l AR* | mail -s "Y a des AR*" foo@bar.com