gaaaaaAab a écrit 1387 commentaires

bien vu, trompé par la NP complétude, j'avais "lu" problème à la place d'algorithme.

http://translate.google.fr/translate_t?hl=fr&ie=UTF-8&am(...)

dans le contexte, insoluble a l'air pas mal.

et aussi, ça serait bien de rajouter des export devant toutes les affectations de variable d'environnement

attention, sécuritaire n'est pas un adjectif pertinent dans le contexte.
Tel un pirate sans vergogne, je cite le TLF :

SÉCURITAIRE, adj.
Conforme à la notion de sécurité publique
Rem. Ce mot est empl. avec une connotation légèrement péj. qui souligne le fait que la défense de la sécurité publique est susceptible d'engendrer des abus de pouvoir.

</maitre capello>

oui, ça devrait être :

Le gouvernement envisagerait de piratager le savoir ?

ça dépend de ce que tu veux dire par "effacé", si tu as juste modifié la table des partitions (à coup de fdisk, diskdruid ou autre gparted), il suffit de recréer la partition telle qu'elle était et tout va bien.

Par contre, si tu as lancé un mkfs.vfat (ou dans le genre) ou cliqué sur le bouton qui fait le formattage du système de fichier, c'est mort.

Le formatage d'un fs par un autre ne touche que la table de partition, n'est-il pas ??
non, il n'est pas.
et j'en déduis que tu es plutôt dans le second cas ... :/

sinon, vu que tu ne réutilises pas du tout la valeur antérieure si jamais elle est présente, tu peux aussi faire systématiquement un delete de la ligne puis un add à la fin du fichier.

ça ferait une plus jolie ligne que ta ligne actuelle, et ça serait plus lisible que mon sed :)

Le sed ne devrait pas retourner un code d'erreur si le search ne marche pas ?

si on en croit ton test, il semblerait que non ;-)

Sed travaille par bloc, et là, tu cherches à lui faire faire une opération sur l'intégralité du fichier. Du coup, pour que sed puisse se charger de ça, il faut le faire travailler sur l'intégralité du fichier (,$).
Ensuite, ça revient à écrire un script faisant une opération quand le fichier match, et une autre quand il ne matche pas.

exemple :

$ cat file1
pattern1 val1
pattern2 val2
$ cat file2
pattern2 val2
$ cat tst.sed
/pattern1/,$ {
 s/pattern1.*/pattern1 val1bis/
 b
}
/pattern1/,$! {
 $ a\
pattern1 val1bis
 b
}

$ sed -f ./tst.sed file1
pattern1 val1bis
pattern2 val2
$ sed -f ./tst.sed file2
pattern2 val2
pattern1 val1bis


mais bon, là, c'était juste pour faire joujou avec sed (et je dis pas que c'est la meilleure syntaxe sed pour ce truc là ...), mais je serais toi, je ferais du grep -l pour décider si tu fais du remplacement ou de l'ajout

il y a aussi épépinage si tu veux faire du 100 % fr (et épépineur donc)

et la lumière fût.
Merci !

ah oui tiens, je vivais dans l'illusion sur ce point depuis quelques années !
merci pour cette utile précision :)

les crochets sont interprétés par le shell avant d'être injectés dans grep, du coup, grep travaille bien sur ce que tu veux greper.
par contre, ps affiche la ligne de commande telle qu'elle a été saisie (donc avec les crochets), qui, du coup, n'est pas matchée par le grep (pour lequel les crochets ont été interprétés par le shell).

comme c'est pas très clair ce que je dis, voici l'exemple :
$ps -edf |grep gre[p]
gab 8436 7580 0 16:19 pts/5 00:00:00 grep gre[p]


truc classique pour éviter le grep -vF "grep" :

$ ps -edf|grep Eterm
gab 7579 28182 0 14:47 ? 00:00:00 Eterm
gab 7685 7580 0 14:50 pts/5 00:00:00 grep Eterm


$ ps -edf |grep Eter[m]
gab 7579 28182 0 14:47 ? 00:00:00 Eterm


sinon, man pidof ?

La question n'est pas de savoir si Miterrand va se planter sur le sujet, mais de savoir quand et comment.

Ayons une pensée émue pour RDDV et l'article 1 qui disparaît et qui ré apparait sous forme d'amendement de heu ... l'article 1 (ouais !), pour Albanel et les socialistes ninjas cachés dans les rideaux, ... on a pas fini de rigoler :D

Le seul truc triste dans tout ça, c'est que pendant ce temps, les auteurs ne sont pas rémunérés comme il faudrait et la culture n'est pas financée comme elle le devrait.

Sinon, si j'en crois les résultats actuels, Pascal Nègre a quelques multis (20 pour l'instant)
on m'indique la direction de => []

de rien, mais la prochaine fois, on te fouettera avec des orties fraîches ;)

s/guillemets/apostrophes/ ...

inverse les guillemets et les accolades, et ça passe :
echo "1 2 3 4/awk" | awk {' print $2" "substr($4,match($4,/\//)+1) '}
devient
echo "1 2 3 4/awk" | awk '{ print $2" "substr($4,match($4,/\//)+1) }'

flashblock \o/

déchiffrer une partition de musique, déchiffrer un message griffonné sur un bout de papier.

ton exemple va plutôt dans le sens inverse de ta démonstration. En effet, dans les deux cas, tu sais comment les données ont été "chiffrées" (solfège et alphabet) et tu te sers de ta connaissance du chiffre pour accéder aux données.

J'utilise chiffrer/déchiffrer et décrypter dans le même sens que Tanguy. Utiliser crypter/décrypter en synonyme de chiffrer/déchiffrer fait perdre en précision. Tant qu'à avoir plusieurs mots, autant qu'ils servent à représenter des choses différentes, non ?

oui, je vois ce qu'on peut faire avec les ACLs. J'ai juste un peu de mal à imaginer des cas pratiques ou vraiment c'est super bien de faire des ACLs fins.
Dans un contexte professionel, il me semble que des groupes pré définis par l'admin sys devrait répondre au besoin. Pour les données professionnelles, la rétention d'information n'est pas vraiment indiquée, et pour les données personnelles de l'employé, des droits limités à l'utilisateur permettent de garantir leur confidentialité.
Reste le cas des données personnelles à partager avec seulement quelques collègues mais est-ce vraiment le rôle d'un service d'infrastructure de se préoccuper de ça ?

En fait, dire que les ACLs fins permettent à l'utilisateur de gérer finement les droits sur ces fichiers, ça ne répond pas vraiment à la question. Au delà de l'utilité immédiate (donner des droits sans créer de groupes), ça s'inscrit dans quel contexte, dans quelle perspective. Bref : ça sert à quoi ?

je savais bien que la formulation était un peu trollesque.

ok, ça servirait moins à rien si c'était plus utilisable. Aujourd'hui (mon avis personnel que je partage), le niveau de complexité côté utilisateur pour la gestion fine des ACLs par rapport à l'intérêt que ça a n'est pas rentable.
c'est vrai que ça fait longtemps que je ne me suis pas penché sur le sujet (pas assez parano ? ;) du coup, ça a peut-être évolué mais je n'y crois pas trop.

Quand on voit que meme les ACL ne sont pas gerees par Gnome (et KDE ?)

ça doit être parce que ça sert à rien. Franchement, les ACL ... qui a *vraiment* envie de passer du temps à définir des droits d'accès super fins ?
Du temps ou j'utilisais Windows en réseau (c'était en école d'ingé y'a quelques années), c'était d'un pénible ... (en même temps, avec une GUI, c'est un peu couru d'avance)

sinon, ça doit aussi être parce que seuls quelques FSs gèrent des ACLs, et en plus, ils gèrent pas tous les même ...

qui sert à rien pour la 12 !
oui, ça sert à rien, mais ça fait quand même du bien :
http://www.marredumarchenoir.fr

non, ça, c'est un cliché !

Ben très franchement, quand il y en a un, ça va. C'est quand il y en a beaucoup qu'il y a des problèmes.