✅ ffx a écrit 583 commentaires

driller ?
je ne connais pas ce mot (à part en anglais, mais ici je ne vois aucun rapport avec le forage)

Les pauses dans son discours sont probablement dues au fait qu'elle cherchait ses mots en Français, langue qu'elle n'a probablement pas parlé depuis longtemps.

L'interruption SIGSEGV est interceptée, et dans la fonction que tu appelles dans ce cas, tu ne quittes pas le programme, donc c'est tout à fait logique que le programme ne se termine plus.
Il faut que tu ajoutes un appel du genre _exit(ERROR_CODE); dans ton quitandclean.

Malheureusement, on ne peut pas s'auto-moinser :(

Ca peut être un problème de PATH...

La séquence que j'ai décrite est déterministe, le fichier DOIT être tronqué avant d'être lu.
Si quelqu'un constate que ça ne se passe pas comme ça, il a trouvé un BUG noyau...

Hmm, pas forcément, les shells sont de plus en plus perfectionnés et peut-être que certains reconnaissent que la commande utilise le même fichier en entrée et sortie ?
Typiquement, un truc qui m'a énervé récemment c'est quand j'ai voulu faire un gunzip sur un fichier sans extension .gz, eh bien la complétion automatique ne fonctionnait tout simplement pas ! (à bas le progrès !)

Je reste perplexe devant le fait que dans l'exemple donné initialement par Nicolas, le fichier $1 ne soit pas écrasé avec sed.
Peu importe que sed soit un éditeur ou pas, normalement c'est au niveau du shell que la redirection est évaluée.
En lisant le "> $1", le shell doit (re)créer (donc vider dans le cas où il existe déjà) le fichier $1, puis il exécute la commande demandée tout en redirigeant la sortie vers le fichier qu'il a ouvert.

Bref, ca ne devrait jamais marcher, peu importe la commande, puisque c'est au niveau du shell que le problème se produit.

D'ailleurs en faisant le test de mon côté, j'obtiens bien un fichier vide tant avec grep qu'avec sed.

Mes tests ont été réalisés avec bash, peut-être que Nicolas utilise un autre shell ?
Sinon je ne comprends pas...

Il y a des gens qui contactent le support pour un jeu qu'ils ont piraté ?

J'aurais cru qu'ils se feraient discrets dans ce cas...

En plus il est bien placé pour savoir que les maisons de disques ne sont pas du côté des chanteurs
http://musique.aol.fr/johnny-hallyday-une-defaite-pour-johnn(...)

A priori je préfère sous chaque paragraphe, c'est comme ca que j'ai appris à faire depuis longtemps, mais...
au bureau je réponds souvent au-dessus.
Et ce, pour une raison principale : il est très courant d'avoir à forwarder toute une conversation à un autre collègue, et c'est largement plus facile et rapide de le laisser lire toute la conversation que d'avoir à expliquer tout le contexte.

Ce que font certains collègues aussi, et je n'ai jamais trop aimé (à cause d'un handicap visuel), c'est de répondre à l'intérieur du message de l'expéditeur, mais dans une autre couleur.

moi c'est surtout parcourut et chaques qui m'ont sauté aux yeux

Euh, non, je ne suis pas comment ;)

ImageMagick sait faire plein de choses qui devraient t'aider :
http://www.imagemagick.org/Usage/compose/#dissolve

c'est possible aussi avec ffmpeg (que je cite car utilisé dans l'exemple de départ) : http://ffmpeg.mplayerhq.hu/faq.html#SEC12

ffmpeg -f image2 -i img%d.jpg /tmp/a.mpg

Moi je suis sincère mais je me trompe. J'ai répondu télé en hertzien alors que c'est télé via adsl. Faut recommencer tout le sondage, désolé.

Pourquoi "pas de guillemets droits surtout" ?

Je me suis inspiré de wikipédia pour parler de guillemets droits, sinon j'aurais simplement dit guillemets mais ca me semblait justement plus ambigu :
* guillemets typographiques (ou français), en forme de chevrons imbriqués : « (ouvrant) et » (fermant) ;
* guillemets anglais : “ (ouvrant) et ” (fermant) ;
* guillemets allemands : „ (ouvrant) et “ (fermant)
* guillemets droits " (sans symétrie) :

Ceci dit, effectivement plus bas ils parlent des noms unicode:
* guillemet anglais (nom Unicode, appelé « guillemet droit » dans l'article) "
* guillemet droit »

Bon, en gros faut appuyer sur le 3 du clavier principal (donc pas le pavé numérique) sans shift quand on est dans le mode standard azerty.

Ne pas oublier les guillemets droits pour ne pas avoir de soucis avec des fichiers qui ont des espaces dans leurs noms.

Et penser à remettre ces alias sur toute nouvelle machine / tout nouveau compte.
Hier encore j'ai fait un "cp script*" au lieu de "cp script* destdir", et je n'avais évidemment que deux fichiers commençant par script...
(heureusement, ce n'était pas très critique, mais ca énerve quand même)

Si le fichier ne doit être lu que par une certaine application, tu peux regarder du côté de setuid : l'application peut être exécutée avec des droits différents de ceux de l'utilisateur, et pourra accéder à des fichiers que l'utilisateur ne peut pas lire directement.

à emporter

Bien que cela ne soit pas ce qui a été demandé (et dd est alors sans doute le mieux, comme écrit plus bas), pour extraire les lignes de 10 à 50 je ferais plus simplement :
sed -n "10,50p" fichier

Je sais, puisque c'est un copié-collé de ton post, avec une modification minime ;)

Oh un journal quantique !
Il est à deux endroits à la fois !
Bon, mais visiblement, poster des commentaires ne suffit pas à repasser dans un état cohérent...

Je ne sais pas si Voltaire a écrit un texte sous ce titre, mais ce dont je suis certain c'est que c'est une célèbre citation de Montaigne, dans ses Essais : http://www.autopacte.org/Montaigne.html#2

On peut en conclure que c'est un cryptage qui modifie le nom des auteurs ;)

et bonne année

Peux-tu me donner un argument rapide qui pourrait me faire utiliser zsh plutôt que bash ?

En général c'est le shell qui transforme le caractère "*" en la liste des fichiers.
Après il faut voir si le programme accepte effectivement plusieurs noms de fichiers en argument. Si unzip (de même que tar en mode extraction) n'accepte qu'un seul nom de fichier archive, c'est parce qu'on peut lui demander de n'extraire que certains fichiers de l'archive.

Certains programmes (grep, sed, find) peuvent interprèter le caractère "*", ce qui fait qu'il faut parfois, euh, l'échapper pour qu'il ne soit pas modifié par le shell.

rsync --progress src dest