gaaaaaAab a écrit 1439 commentaires

Pour préciser d'où je parle, j'ai participé à une paire d'actions avec le collectif stopdrm (distrib de tract et autres).

Une loi n'est pas gravée dans le marbre : pourquoi ne pas continuer le lobbying légal ?

C'est prévu, mais il n'y a pas d'activité parlementaire sur le sujet pour le moment. Il faut continuer à informer. Aller se dénoncer quelque part, c'est aussi une opération de com'. C'est pas juste pour le plaisir de la confrontation avec l'autorité de l'état ...

ouais, d'ailleurs comme tu es bailloné, tu te proposes de violer la loi sous couvert d'un motif idéologique pour qu'on entende ton cri d'alarme.

baillonné ?! (j'hallucine, je vois pas d'ou tu sors ça là). non, c'est plus simple que ça. Quand tu achètes un truc, si t'es pas content, tu vas râler auprès du vendeur jusqu'à ce qu'il te rembourses.

Certains crament des bagnoles, fracassent des radars automatiques ou démontent des mac do pour les mêmes raisons. C'est beau l'action citoyenne de certains.

super comparaison. C'est clair que lire un dvd sous linux, ça porte atteinte à la sécurité de l'état ...

Ce n'est pas parce que tu as le droit de faire une copie privée qu'on doit te donner les moyens de le faire (jurisprudence que j'ai la flemme de retrouver).

Certes. Sauf que là, en plus de ne pas te donner les moyens de le faire, on t'interdis d'en trouver. C'est légal, mais c'est quand même super hypocrite. Surtout que tu payes toujours la redevance pour copie privée sur les média vierges. Au bout d'un moment, moi, ça me gonfle d'être pris pour un con (surtout que les média vierges en question, ça m'arrive de m'en servir pour d'autres trucs que de la musique ou des films ...)

Gné ? Tu as totalement craqué là. Quand tu achètes un truc dépendant d'un autre (genre un morceau iTunes dépendant d'IPod) je ne vois pas où est la vente liée.

alors si c'est pas de la vente liée, je suis curieux de ta définition de la vente liée. Sinon :
http://tempsreel.nouvelobs.com/actualites/medias/multimedia/(...)

Plutot que se mettre dans l'illégalité, ne vaudrait-il mieux pas essayer de soutenir légalement les structures qui proposent du contenu sans ces saloperies ?

si tu lisais régulièrement stopdrm.info, tu verrais passer des billets pour parler des initiatives en ce sens (un exemple parmi d'autres : http://stopdrm.info/index.php?2006/12/20/126-c-est-noel-des-(...) ). Je ne sais pas bien ce que tu penses de stropdrm.info mais j'ai l'impression que l'image que tu t'en fais est un peu fausse.

Pour faire avancer les choses il existe heureusement d'autres actions que les actions illégales. Celles d'EUCD.info ont jusqu'ici toujours été légales et dans le bon sens

Arrête un peu avec le couplet de l'illégalité. Il faut relativiser un peu. Quand tu ne payes pas ton parking ou que tu te gares sur une place de livraison, c'est illégal aussi ...

L'action proposée par StopDRM.info n'est pas crédible car elle remet en cause un texte voté et validé par l'état, autant dire qu'elle remet en cause les mécanismes de l'état => ce sera directement dirigé dans la case poubelle et étiqueté "action José Bové".

ah oui ! comme les étudiants dans la rue contre le CPE ? clair qu'ils se sont fait calmé tout de suite là ... ;)

ton /etc/passwd fait probablement partie des fichiers que ton système n'arrive plus à lire :/
dans ces cas là, le système n'arrive pas à faire le lien entre ton id et une entrée de ton fichier de mots de passe et il te dit (de mémoire) : "you don't exist. Go away !'.
Enfin il disait ça y'a quelques années quand j'ai accidentellement éclaté le /etc d'un ami ...

essaie de booter sur une distrib live puis de monter tes partitions pour essayer de comprendre un peu mieux ce qui se passe.

à partir de là, quelques typedef et un cast bien placé devrait simplifier l'accès aux données

Dans la question de vérification d'intégrité par la base de donnée avec des contraintes, la base rejetant les enregistrements fautifs, il faut que le code "capture" le rejet de la base et l'analyse pour expliciter le pourquoi du rejet à l'utilisateur.

oui ! Si t'arrives à faire ça, c'est cool =)
De ce que j'ai vu, le plus souvent, l'analyse de l'erreur se résume à "database error" ou "inconsistent data", pis après, démmerde toi ... :/

N'est-il pas plus facile et plus performant en terme de rapidité de vérifier l'intégrité par le code AVANT insertion, plutôt que de faire un système de gestion d'erreur qui explique ensuite pourquoi la commande n'a pas été effectuée et a été rejetée ?

Excellente question. Pour moi, ça dépend de tes données. Si statistiquement, les incohérences des données en entrée sont rares, la majorité de tes tests d'intégrité en amont ne servira à rien donc tu perds en perfo si tu testes tout avant. Si tes données en entrée sont très souvent moisies, ça peut valoir le coup de faire tes tests de diagnostic avant de tenter l'insertion.
Comme pour *toutes* les questions de perfo, il faut benchmarker avec des données et des volumétrie de prod.

il vaut mieux que ca marche pas sans explications plutôt que ca marche alors qu'il ne faut pas ?

alors là, une seule réponse possible, si les données sont foireuses, il ne faut *pas* que ça marche. La correction (le fait de se comporter correctement) d'un logiciel est une de ses qualités essentielles. Pourquoi ? parce que l'erreur se propage. Si une brique de ton soft laisse passer des données incohérentes, l'incohérence se propage dans tout le reste du soft, et tu as vite fait de te retrouver avec une base de données indémmerdable (données contradictoires, incomplètes, fausses, doublons fonctionnelles, ...) qui entraîne des plantages applicatifs (à moins que le soft ait été codé dès le départ en postulant que les données en base n'étaient pas fiables, et encore ...)

T'es obligé de faire ça en C ou tu as choisi le C parce que c'est le langage avec lequel tu es le plus à l'aise ?

Je demande ça parce que les langages de script sont particulièrement adaptés au traitement de données dans des fichiers (c'est limite pour ça qu'ils ont été conçus). Je pense à Perl, Python, ... voire même avec les commandes de shell usuelles ...

Dans ce cas là, un redémmarage et udev va gentiment tout recréer pour toi.

juste pour lever une ambiguité potentielle, un redémarrage de udev suffit, même pas besoin d'un reboot !

en fait, c'est normal. C'est directement le fichier de syntaxe xml qui définit quelles sont les zones de texte à vérifier.
cf /usr/share/vim/vim7/syntax/xml.vim :
syn region xmlString contained start=+"+ end=+"+ contains=xmlEntity,@Spell display
syn region xmlString contained start=+'+ end=+'+ contains=xmlEntity,@Spell display
et :help spell

Deux solutions :
- tu vides la syntaxe du fichier (:set syn=) et la vérification orthographique s'applique à tout le fichier (y compris les balises)
- tu personnalise le xml.vim pour étendre la vérification de l'orthographe aux zones qui t'intéresses.

Cela dit, j'aurai quand même tendance à dire que le comportement par défaut du fichier de syntaxe xml.vim est le plus logique. Les seules zone dont l'orthogrape a un sens sont les chaînes de caractères dans les données.

ah oui, vim 7 fait du spell check de base. Je pense que ma question est hors sujet du coup ...

Je ne pourrais surement pas répondre à ta question, vu que je n'utilise pas de correcteur orthographique, mais par curiosité, quel script utilises-tu ? vimspell ?

tout pareil, sauf que j'ai tendance à garder le .. pour les recherches sur le répertoire courant :
- ça permet de bien se rendre compte que find prend un répertoire en paramètre (. par défaut). Bien s'en rendre compte évite de faire systèmatiquement un cd dans le répertoire cible avant de lancer find. (En tout cas, moi, ça m'aurait évité pas mal de cd inutiles si je l'avais su plus tôt ... ;-)
- c'est plus portable, vu que les find non Gnu ont furieusement tendance à exiger que le répertoire cible soit passé en paramètre.

mes 2 centimes

ça devrait le faire :
echo ${!titi}

cf http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_04.htm(...)

par contre, je pense que c'est pas compatible avec d'autres shells. (C'est déjà pas compatible ksh chez moi)

hourra pour Google, prophète du grand 'Ternet ! ;-)

petit détail en passant, si tu as une molette, tu as une souris 3 boutons. Tu dois donc pouvoir faire sauter les options Emulate3*.

c'était avec plaisir. Ca rappelle des souvenirs :-)
je me souviens d'être resté longtemps coicé sur select, dans genre appel système imbittable tant que t'as pas lu 97 fois le man ;-)

en tout cas, je veux plus voir de questions sur stat !

"faut-il le pathname en entier depuis la racine ?"

on y vient ! on y vient !
Effectivement, ton souci vient de l'appel à stat.
prenons l'exemple ou tu appelles ton prog sur /etc à partir d'un autre répertoire

Du début à la fin, readdir travaille sur /etc
par contre, stat fonctionne avec des chemins relatifs ou absolus.

Du coup, pour les entrées . et .., chance (façon de parler, c'est pas vraiment de la chance en fait), stat arrive à les trouver dans le répertoire local et te renvoie les droits de . et de .. du répertoire courant => ce qui explique tes problèmes de users faux sur . et ..

à partir de là, readdir va continuer à te lister les fichiers de /etc, mais comme tu appelles stat directement avec leur nom, stat les cherche dans le répertoire local, et, ne les trouvant pas, te crache une erreur ENOENT.

il suffit de corriger ton appel à stat pour "stater" les fichiers dans leur répertoire et ça devrait être bon.

ouala :-)

"je pense pas que mon script soit sujet a une de ses erreurs"

es-tu bien sur ? que vaut le errno en retour de stat ?
(cf man errno, strerror, ...)

autre indice, si tu fais un cd /etc et que tu appeles ton prog sur . ensuite, ça fonctionne bien.

stat() stats the file pointed to by path and fills in buf.

attention, c'est ton dernier essai, la réponse au prochain commentaire hein ! :-)

ouaip, t'es sur la bonne voie. Y a plus qu'à comprendre pourquoi stat renvoie une erreur. Relis attentivement le man et le prototype de stat.
Pour rappel, . désigne le répertoire courant, et .. le répertoire parent et sont donc présent dans tous les répertoires.

ps: chez moi, ton prog fonctionne très bien s'il est lancé sur le répertoire courant (./<prog> .). C'est quand on le lance sur un autre répertoire que ça ne fonctionne pas.

C'est beaucoup plus simple que ça.
Suis le conseil d'alveric et test le retour de ton appel à stat (parfois, il échoue).

Si tu es joueur, je te laisse creuser dans cette direction tout seul (c'est toujours plus gratifiant de comprendre par soi même), à moins que tu en aies super marre de chercher et que tu aies besoin d'une réponse urgente. (A ce moment là, dis-le, et je te proposerais une explication)

mouhahaha !
oui, ben on l'a tous fait je crois ... en tout cas, moi, je l'ai fait ;-)

et la réponse est "non !" :-)

indice : ton prog fonctionnera toujours bien si tu l'appelles dans le répertoire courant. (genre tu te déplaces dans /etc, et tu appelles ton prog à partir de là).
ça te met sur la voie ?

sinon, c'est une assez mauvaise idée d'appeler ton prog 'exec', puisqu'il y a déjà une commande qui porte ce nom. Essaie de trouver mieux ...

mv étant atomique, l'idéal, si tu as la main sur le bout de soft qui pond les fichiers, c'est de générer un fichier temporaire et de le déplacer une fois qu'il est complet.

ouaip, ça marche :)
C'est juste dommage que la syntaxe de ton bloc awk soit horrible, mais j'ai déjà écrit ce que j'avais à dire là dessus dans mes commentaires précédents.

Il faut juste que tu te rendes bien compte que ta syntaxe actuelle montre que tu n'as pas bien compris le fonctionnement de awk (ce qui n'est pas une critique en soi).

Si c'est du one shot et que tu ne comptes plus jamais toucher une ligne de commande de ta vie, c'est pas bien grave. Par contre, si tu vas être amener à utiliser régulièrement ce genre d'outil, je t'invite à t'arracher un peu pour comprendre exactement ce que fait ce bout de script. Ca te fera gagner du temps à l'avenir ...

mouais, en lisant les autres commentaires, je vois que je répond un peu à côté de la question aussi. Les variables d'environnement du shell sont tout à fait adaptées au problème.
motif=`head temp`
yapuka (c) utiliser la variable motif en lieu et place de ma_chaine dans la ligne de sed (je laisse totof2000 gérer le awk ;) par exemple :
sed -e 's/$motif/toto/' fichier > fichier.tmp

si on veut que ça soit un peu illisible, on peut même tout faire en un coup :-)
sed -e 's/'`head temp`'/toto/' fichier > fichier.tmp

encore une fois, je recomamnde fortement la lecture d'un tutoriel pour t'approprier un peu mieux les possibilités offertes par le shell.

Tu peux utiliser un pipe ('|').

head -1 fichier | awk ...
ou head -1 fichier | sed ...

essaie quand même de jeter un oeil au premier tutoriel shell venu (suffit de demander à google), par exemple là : http://marcg.developpez.com/ksh/
Parce que là, c'est une question super basique.

sinon, ton $0= 'toto' est inutile, tu peux directement faire un print 'toto'
en remarque bonus, utilise plus une des solutions proposées en sed. awk s'utilise plutôt quand on veut faire des trucs un peu plus compliquées qu'un simple remplacement.
sed -e 's/<motif>/<remplacement>/' fichier > fichier.tmp

bon allez, mode sympa on. En sed, je ferais un :
head -1 fichier | sed -e 's/ma_chaine/toto/' > fichier.tmp

en awk :
head -1 fichier | awk '$0 ~ "ma_chaine" { print "toto"}' > fichier.tmp

et dans les deux cas, pour finir :
mv fichier.tmp fichier

cool la fonction "zip", je connaissais pas encore =)

sinon, pour le unzip, j'aurais plus fait un :

modes['f'] = [ i[0] for i in fc ]
modes['coef'] = [ i[1] for i in fc ]

qui me parait plus lisible

bien tenté, mais sur ce coup là, pas de bol, les deux étaient bien lancés en mode texte (machine distante, pas de export DISPLAY, toussa). Le résultat de mon test a autant de valeur que le tien. Je voulais juste souligner le fait qu'un unique test sur un unique fichier sur ta machine à toi ne permet pas de tirer la conclusion définitive que tu en tires. La preuve, un test sur un unique fichier sur une autre machine donne des résultats différents.
D'autres part, aucun de nous deux n'a précisé les versions de chaque appli qu'il utilise, ni les options avec lesquelles elles ont été compilées.

Bref, tout ça pour dire que ça fait un peu juste pour affirmer tel éditeur est plus lourd que tel autre.

En vrai, les performances comparées des deux éditeurs, je m'en fous un peu. J'utilise vim parce que j'aime le concept mode édition / mode commande et que j'ai plaisir à m'en servir (il se trouve que c'est mon outil de travail principal).

Sinon, ton commentaire confirme la conclusion de mon commentaire précédent :-)