gaaaaaAab a écrit 1399 commentaires

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/

ouaip, d'accord avec toi sur le fond. Le problème, c'est le timing :
Balancer une nouvelle en page d'accueil sur Mono (quelques soit la qualité de la rédaction de la nouvelle en question) alors qu'on est en plein troll MS/Novell, c'est, au mieux, peu judicieux ... ;-)

un commentaire éventuellement hors sujet.
Je ne doute pas que le bout de glib fasse ça très bien, mais as-tu vraiment envie de te cogner une dépendance à la glib pour un pauvre parsing de fichier ?

si tu fais une appli gnome, je retire ce que j'ai dit :-)

http://ndevilla.free.fr/iniparser/

enjoy ! :-)

je m'auto commente parce que finalement, je me moinsserais presque sur mon commentaire précédent :-)
l'impression que j'ai, c'est qu'une protection qui ne s'appliquerait qu'aux utilisateurs de Novell/Suse, c'est tout sauf bien. On aurait les utilisateurs de ladite distrib' bien "protégés" par le parapluie Novell/MS qui du coup seraient nettement moins sensibles aux problèmes que les autres distrib' pourraient rencontrer avec MS.

Diviser pour régner, c'est un des tout premiers trucs qu'on apprend quand on fait de l'info. Ca ne s'applique pas qu'au code ...

Ben au moins Mono reste une plateforme dont on a une certitude juridique vis-à-vis de MS.

pouf pouf
une citation de jean michel à peu près : "ceux qui échangent leur liberté contre la sécurité ne méritent ni l'une ni l'autre"

Quelque soit la façon dont tu fais ton boot (lilo ou grub), tu dois pouvoir passer des options au noyau. L'option intéressante du noyau est l'option "single" qui boot en mode single à partir duquel tu dois pouvoir faire la maintenance de ton système..

Si c'est du grub, tu choisis l'entrée grub à booter, tu tapes e (pour edit), tu te positionne sur la ligne ou tu appelles le noyau (la seconde je crois), tu rechoisis de l'éditer (e) et tu rajoute juste "single" à la fin.

Pour Lilo, c'est un peu plus loin dans ma mémoire. J'aurais bien une ou deux suppositions, mais je n'ai pas de quoi tester sous la main alors je m'abstiens. Google devrait savoir :)

voui, le live cd qparted, c'est cool.
Ca m'a permis de redimensionner la partoche ntfs système sur l'ordi du paternel sans télécharger un shareware moisi ou craquer le super soft de la mort qui le fait nickel et qui coute la peau du cul pour une utilisation en one shot =)

pour info (c'est du retour d'expérience comme on dit en consulting language), j'ai juste eu un petit souci parce que le live cd de qparted voulait absolument regarder ce qu'il y avait comme partition sur /dev/fd0 et comme y a pas de lecteur de disquette sur le bousin, qparted bloquait littéralement.
Un bête rm /dev/fd0 (même pas peur, c'est du live) et un appel à qparted directement depuis la ligne de commande plus tard et tout marchait bien partition.

Mais cfdifsk m'indique espace inutilisable pour la 5 partition ... que faire ?

heu là, c'est un peu obscure. Si tu peux nous coller le résultat du print de fdsik, ça nous aiderait :-)

ton fichier n'aurait-il pas des fins de lignes au format windows ?

pour vérifier ça, tu l'ouvres avec vim. Si ton fichier est au format dos,
dans la ligne de status, tu auras
"test.sh" [dos] ...

Si c'est le cas, tu peux facilement le convertir au format unix, en faisant (toujours sous vim) :

:set ff=unix
:x

ou en utilisant dos2unix

ouais ! j'ai retrouvé le fil que je cherchais :
http://linuxfr.org/forums/26/17953.html

notament :
http://linuxfr.org/comments/737316.html#737316

vive l'option -C de ps =)

> >Ce post était une pure critique non constructive
> Attends, si tu critiques ton post qui est criticable, ca devient un post pertinent, donc tu n'as pas de raison de le critiquer, mais alors si... récursion infinie.

ben non, la non pertinence du post étant transitive, toute réponse à un post impertinent est non pertinente (ouf, pas de récursion infinie, le monde est sauvé !)

> >je vais continuer à tout lire à -42
> Ca va être indispensable pour lire mes commentaires !

et oui, la vie est dure ;-)

effectivement, le produit de la modération ici laisse à désirer (comparé, au hasard, avec le résultat de la modération sur /.)
Ce post était une pure critique non constructive. Je ne vais pas proposer de patch et je vais continuer à tout lire à -42 ! :-)

rhalala mais moinssez pas ça !
Ca doit être le seul commentaire à sauver de l'enfilade (oui, je choisis mes mots avec soin ;-) ci dessus. C'est un machin, ça s'appelle "humour" je crois :p