gaaaaaAab a écrit 1387 commentaires

à 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 :-)

je voulais faire le même comparatif pour voir ce que ça donne sur ma bécane, mais j'y arrive pas. J'ai le message d'erreur suivant:
-bash: emacs: command not found
quelqu'un saurait d'ou ça peut venir ? ;-)

bon, j'ai réussi à trouver une autre bécane, en faisant les même manips que toi, ça donne ça :
$ grep ^Vm /proc/`pidof emacs`/status
VmSize: 11944 kB
VmLck: 0 kB
VmRSS: 5672 kB
VmData: 948 kB
VmStk: 204 kB
VmExe: 1324 kB
VmLib: 6256 kB
VmPTE: 36 kB
$ grep ^Vm /proc/`pidof vim`/status
VmSize: 8844 kB
VmLck: 0 kB
VmRSS: 3096 kB
VmData: 1296 kB
VmStk: 88 kB
VmExe: 1804 kB
VmLib: 5308 kB
VmPTE: 32 kB

quelle conclusion en tirer ?
facile, le troll vim/emacs a encore de beaux jours devant lui :p

petite typo sur l'url (hint : il faut mettre un espace après l'url)
donc http://www.psil.fr/