gaaaaaAab a écrit 1431 commentaires

je viens de jeter un oeil au man. En fait, si, on peut en awk, et c'est en fait beaucoup plus simple (donc beaucoup moins rigolo ;) qu'en sed ...
pour reprendre mon exemple précédent :
echo $ echo 1234567890abcdefghijABCDEFGHIJ1234567890abcdefghijABCDEFGHIJ1234567890 |awk '{print substr($0, 22, 4) " " substr($0,47, 9) " " substr($0,56,9)}'
BCDE ghijABCDE FGHIJ1234


bon, on peut dégainer du sed alors, mais ça va pas être très lisible ...
Par exemple, pour les intervalles de ta question de départ ("22-25,47-55,56-64")

$ echo 1234567890abcdefghijABCDEFGHIJ1234567890abcdefghijABCDEFGHIJ1234567890 |cut -c"22-25,47-55,56-64"
BCDEghijABCDEFGHIJ1234


D'après ton propre aveu, tu n'es pas une grosse brute en sed, on va donc construire la commande pas à pas. Tu peux aller te faire peur en allant direct à la fin du commentaire, mais une fois que tu auras lu ce petit pavé, ça devrait être claire comme de l'eau à peine croupie ;)

On va utiliser sed suivant la syntaxe suivante :
sed -e 's/<pattern>/<replacement>/'
qui permet d'appliquer une regex. Dans cette regex, il faut définir un motif capable de représenter les découpes qu'on veut faire dans la ligne de départ.

rapidement :
^ symbolise le début de ligne
. remplace une occurence d'un caractère quelconque
{ et } permettent de "compter" des motifs
( et ) permettent d'extraire les bouts de lignes pour les réutiliser dans la chaîne de remplacement.
* match n occurences du motif qu'il suit.

Pour le motif de recherche, on peut construire quelque chose comme:
^.{21}(.{4}).{21}(.{9})(.{9}).*
le .* à la fin représente la fin de la ligne (tous les caractères entre la position 65 et la fin de ligne)

Pour la chaîne de remplacement, c'est beaucoup plus simple. On va utiliser une série de chiffres représentant le numéro du motif entre parenthèse de la chaîne de recherche. Autrement dit, 1 va correspondre au groupe de 4 caractère, 2, au premier groupe de 9 et 3 au second groupe de 9.

on aura quelquechose comme :
sed -e 's/^.{21}(.{4}).{21}(.{9})(.{9}).*/1 2 3/'

sauf que j'ai légèrement simplifié. Les chiffres représentants les blocs entre parenthèses dans le motif de remplacement doivent être échappés par un \, sinon, ils représentent simplement des chiffres.
sed -e 's/^.{21}(.{4}).{21}(.{9})(.{9}).*/\1 \2 \3/'

et même qu'en fait, j'avais beaucoup simplifié, parce qu'il faut aussi échapper les accolades et les parenthèses, et d'un seul coup, c'est le bordel :

$ echo 1234567890abcdefghijABCDEFGHIJ1234567890abcdefghijABCDEFGHIJ1234567890 | sed -e 's/^.\{21\}\(.\{4\}\).\{21\}\(.\{9\}\)\(.\{9\}\).*/\1 \2 \3/'
BCDE ghijABCDE FGHIJ1234


bref, sur le principe, pas très compliqué de faire ça en sed, mais pas très lisible ...
Je dirais même que ça doit être plus lisible avec un one liner en perl :D

bon, ça n'explique pas pourquoi ton cut n'applique pas l'ouput delimiter.

tu peux poster ta ligne de cut avec ton output delimiter qui ne fonctionne pas ?

parce que chezmoisamarche:

$ echo "aaa" | cut -c1,2,3 --output-delimiter="|"
a|a|a


ou ":x"

Pourquoi "grep" ?
parce que je travaille sur des projets assez volumineux pour lesquelles les implémentations de toutes les fonctions ne sont pas contenues dans un seul fichier ;)
effectivement, pour de la recherche interne au fichier, /, n, N, ?, * et # sont mes amis


Ce que je reproche aux ctags (à part ne pas gérer tous les langages, mais ça, c'est un peu de la mauvaise foi), c'est de remplacer mon buffer en cours d'édition par un autre truc, or, la plupart du temps, je veux voir la définition d'une fonction, mais je veux aussi continuer à voir le code que j'étais en train de consulter.
Y a surement (ou pas ?) pleins de raccourcis dans ctags qui me permettraient de m'en servir "comme j'aime" mais j'avoue piteusement que j'ai la flemme de regarder :)

Comme Maxime, je fais tout en vim.
ça m'est même arrivé de débugger du Java avec =)

par contre, soyons honnéte, j'utilises vim *et* grep. Sans grep, ça serait plus compliqué et je serais obligé d'utiliser les ctags, que j'aime pas trop.

Question modérément trollifique : y'a-t-il d'autes éditeurs que vi (ou vim ou dérivé) utilisant le paradigme mode de commande / mode d'édition ?

parce qu'au final, c'est quand même bien ça qui fait que vim est supérieur à tous les autres éditeurs de texte.

(jolie conclusion non ? :)

oula, fatigué moi
s/ est/, et/

oui est les vrais libristes utilisent la distribution GNU/Linux gNewSense, non mais ! :)

unsigned byte, soyons précis :)

il faut bien renvoyer un statut dans exit et *surtout pas* des datas.
Accessoirement, on ne peut pas renvoyer trop de status non plus.
En tout cas, chez moi :

$ cat main.c
#include <stdlib.h>
int main (int argc, char *argv[]) {
int exitValue = -1;
exit(exitValue);
}
$ gcc main.c; ./a.out; echo $?
255

autrement dit, mon shell récupère un unsigned byte.

pour la conf des runlevel, j'ai mis le temps à retrouver parce que je ne m'en sers pas tous les deux jours, mais sur debian, sysv-rc-conf (en curses), c'est bien pratique.

Concernant l'édition de fichiers de conf, y a-t-il vraiment moins de fichiers à modifier sur d'autres distribs ou est-ce juste que les clickodromes vont modifier les fichiers de confs à ta place ?

Perso, je fais tout en CLI (j'aime bien comprendre ce que je fais) mais je ne connais vraiment bien que les dérivées de Redhat et debian, pour lesquels la différence de complexité ne me parait pas évidente.

tant qu'on y est :
s/mémo-technique/mnémotechnique

oui, car l'algo de google est infaillible, forcément.

bon, j'ai farfouillé un peu.
http://www.blogbilger.com/blogbilger/2006/11/le_journalisme_(...)
Mon expérience personnelle depuis 2003 n'a cessé de me le démontrer. Le fact checking ne fait pas partie de la culture du journalisme à la française

Du coup, tu as raison sur le fait que l'expression "fact checking" désigne quelque chose qui n'a pas de traduction française répandue.

Encore une fois, ne connaissant pas le terme "fact checking", ce n'était pas sur l'utilisation du terme anglais que je tiquais, mais sur la justification que tu donnais.

Qu'il soit maintenant admis que "fact checking" peut rester non traduit et désolé pour le bruit :)

Il se passe quelque chose entre 18.232095 et 196.734335, mais lp n'est pas forcément le coupable. Ca peut aussi être le chargement du module pour le touchpad qui prend du temps.

si tu désactives le touch pad, il se passe quoi ?

le chargement du module lp à la main après le démarrage de la bécane prend combien de temps ?

google ne propose pas de traduction donc c'est impossible à traduire en français ?
Genre "vérification des faits". D'autant que tu utilises déjà le mot "vérification" dans la phrase précédente de ton commentaire originel.

C'est pas tant le fait que tu utilises "fact checking" qui me gène que la très mauvaise justification que tu donnes (google ne sait pas donc on ne peut pas traduire) qui me fait réagir.

ouais ! \^.^/

Je vous rassure, c'est pas une guerre :)

Et puis, plus y a de solutions proposées, mieux c'est (mon petit côté Perl ;)

Sinon, c'est aussi possible de remplacer le syslog fichier par un syslog qui stocke en DB. Ensuite, trouver l'info de départ, c'est un simple SELECT dans la dite DB

Sachant qu’une requête sur une image retourne toutes les informations associées, cela fait quatre jointures par requête.

et alors ?
Si tu penses que ça peut poser des problèmes de perf, tu as peut-être raison, mais c'est beaucoup trop tôt pour s'en soucier. Privilégie la propreté du design de la DB, et implémente les requêtes qui vont taper dedans.
Si un jour tu rencontres un problème de perf, il sera temps de réfléchir à la façon d'y faire face ... mais pas maintenant.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth

sinon, une remarque en passant, il peut y avoir plusieurs villes portant le même nom dans un même pays.

tiens, il reste un artefact de mes tests dans la ligne de grep, les '\(' et '\)' n'y servent à rien. La ligne suffisante est
grep -o "to=<[^>]*>" fichier

Effectivement, awk/sed sont les outils qu'on va assez vite dégainer pour traiter des flux de texte. Je suis tombé l'option -o de grep il y a peu de temps. Elle n'est pas portable mais si tu es sous Linux, ça serait dommage de se priver.

$ echo "blablabla to=<addr1@machin.truc> bliblibli to=<addr2@truc.bidule>" > fichier
$ grep -o "to=<\([^>]*\)>" fichier
to=<addr1@machin.truc>
to=<addr2@truc.bidule>


Ensuite, yapuka (c) enlever les petits morceaux qui traînent avec l'outil de ton choix. Par exemple en pipant dans un sed du genre
(...) | sed -e 's/to=<\(.*\)>/\1/'


En sed pur, on peut aussi faire des trucs, mais c'est un peu moins lisible, et la solution que j'ai ne peut traiter qu'une seul adresse par ligne (ce qui à priori n'est pas trop grave pour ton cas mais bon :)
sed -ne '/to=</,/>/ s/.*to=<\(.*\)>.*/\1/p' fichier

pour en savoir plus sur sed:
http://www.commentcamarche.net/faq/478-sed
http://www.grymoire.com/Unix/Sed.html

j'ai pas dit "étonnant", j'ai dit "marrant" :)

C'est pas t que 4chan "lance" quoi que ce soit. La plupart du temps, ça reste très underground. La majorité des fils de discussions sont des gigantesques troll fests, faites d'hybridages permanents de références multiples et croisées. Pour moi, c'est un peu comme une soupe primitive avec une cohorte de bactéries interagissant au hasard.

http://gawker.com/346385/what-the-hell-are-4chan-ed-somethin(...)

Faut bien comprendre que 4chan n'est qu'une infrastructure technique. Tout ce qui vient de 4chan vient en fait de la "communauté" des utilisateurs. Comme il n'y a pas de login, pas de noms d'utilisateurs, le résultat est une espèce d'hydre à 1000 têtes. Du coup, dans l'article d'infos du net, 4Chan indique à tous ses utilisateurs, ça ne veut rien dire. Deux formulations correctes seraient "4Chan indique à 4Chan" ou "des utilisateurs de 4Chan indiquent à d'autres utilisateurs"

Pour répondre à ta question initiale (oui, enfin ;), dans tout le fatras qui passe sur 4chan, de temps en temps, y a des trucs qui émergent et qui évoluent en quelque chose d'autre.
- parfois sérieux :
Il y a quelques temps, on avait un peu entendu parler d'Anonymous (mais pas trop en France) contre la scientologie: http://en.wikipedia.org/wiki/Project_Chanology
- La plupart du temps, c'est du n'importe quoi :
http://icanhascheezburger.com/
http://musicmachinery.com/2009/04/15/inside-the-precision-ha(...)
le rickrolling, effectivement
Sûrement d'autres trucs dont l'origine est 4chan mais dont on ne connaît que la vitrine publique.

dans toutes les actions qui prennent un peu d'envergure, l'objectif initial, c'est toujours plus au moins de se fendre la gueule, éventuellement aux dépends d'un sinistre.

Attention, je le répète, la majorité du trafic sur 4chan, c'est quand même du troll (avec toutes les interventions racistes, misogynes, révisionnistes qu'on peut attendre d'un nid à trolls) et du pr0n, 'videmment ;). N'allez pas traîner là bas en pensant assister à un feu d'artifices de contributions toutes plus stupéfiantes les unes que les autres, vous seriez déçus :D

Pour /b/, faut pas oublier de lire les petits caractères:
The stories and information posted here are artistic works of fiction and falsehood.
Only a fool would take anything posted here as fact.

oui, le format est débile, si tu considère que l'objet du message est de diffuser un contenu. La, clairement, le contenu est très faible. C'est de la com'

L'article d'infos-du-net est vraiment mauvais. Vu la façon dont c'est présenté, on a l'impression qu'il y a eu un gros figth entre ATT et 4chan et que c'est une sorte de fait historique. En fait, cf le billet du 27 Juillet ici : http://status.4chan.org/ et http://www.att.com/gen/press-room?pid=4800&cdvn=news&(...)
bref, de la pure anecdote.

La conclusion, c'est du bonheur Aux vues de ces recommandations, on est tenté de croire à la création d’un mouvement de panique visant à déséquilibrer la Toile. Tiendra-t-elle le choc ?
Si c'est pas risible comme conclusion ça ! :D

http://tempsreel.nouvelobs.com/actualites/vu_sur_le_web/2009(...)

Pour TechCrunch, ce "grabuge" de 4Chan vise à "créer un ennui généralisé" pour atteindre l'effet "hilarant de voir tout le monde paniquer", plutôt qu'annoncer une réelle menace.
ouais, bien possible ça.

Marrant de voir les média tomber encore une fois dans le panneau du "on vous en parle mais peut-être que leur objectif, c'est juste d'en faire parler".

heu ... venant de 4chan, c'est assez peu probable :D