gaaaaaAab a écrit 1431 commentaires

la commande motd n'existe pas, n'existe pas, n'existe pas, n'existe, pas non non n'existe pas—Les betteraves (à peu près)

il y a juste le fichier /etc/motd qui sert de point de synchronisation. Ensuite, il peut y avoir des softs pour changer le motd (genre un truc qui va mettre une nouvelle fortune tous les jours), et des softs pour le lire et afficher son contenu.

c'est succinct mais cf Motd_(Unix)

ça ne sert pas à la même chose.
Quand je suis en train de greper des trucs dans des dizaines de milliers de lignes de logs réparties dans plusieurs fichiers pour essayer d'analyser un problème, je suis sacrément content de pouvoir le faire à la volée directement dans le shell. Ça me gonflerait de devoir passer par Python pour ça (et pourtant, Python est un langage que j'apprécie beaucoup et que j'utilise de préférence à d'autres dès que c'est pertinent).

Edit: je surréagis un peu là, je lis ton commentaire comme une critique du shell, alors c'était plutôt contre le fait d'écrire des scripts en shell, ce qui est un peu différent. Mais comme j'ai déjà écrit et posté ce commentaire, je le laisse, avec cet ajout.

ah, j'avais raté un aspect du problème !

à mon avis, il faut rentrer plus finement dans la compréhension de ce que représente ce status pour ne pas se tromper de solutions. De deux choses l'une:

• soit la liste des status possibles est définie au niveau de la DB. Du coup, le status mériterait d'être modélisé par sa propre entité, et une clause "group by" et une jointure externe devrait permettre de produire le résultat que tu attends,

• soit (le plus probable) la liste des valeurs possibles pour le statut est définie par l'application qui alimente la DB, et dans ce cas, il va falloir s'assurer qu'il n'y a jamais de divergence entre la liste des status définis par l'application et ce que produit generate_series. En plus, si, au fil du temps, certains status sont rendus obsolètes, et qu'il se met à y avoir des trous dans la séquence des différents status possibles, ça va pas être simple à reproduire via generate_series.

pour conclure, à long terme, je pense que generate_series pose un sérieux problème de maintenance. En fonction de ce que représente précisément ce status, soit je l'ajouterais explicitement en DB et je m'en servirais en jointure externe, soit je laisserais la couche applicative ajouter la série de couple (valeur_status, 0) nécessaire pour avoir la liste complète.

la clause GROUP BY sert exactement à faire ce genre de trucs. Je n'ai pas de postgres sous la main, mais en Oracle, ça pourrait s'écrire:

SELECT   status, count(*)
FROM     ta_table
GROUP BY status;

c'est une des meilleures fin qui existe.

mouais … c'est assez subjectif.
Très bon bouquin cela dit, et la Zone du dehors (du même auteur), c'est aussi très bon.

bon, ok, Baxter, c'est bien, de là à en mettre 3 dans une liste de 10 …
je propose d'en remplacer deux par:

L'homme des jeux - Iain M. Banks
Un feu sur l'abîme - Vernor Vinge

rien que de les citer, j'ai envie de les relire !

ah tiens, merci, et désolé pour le doublon.
j'avais cherché dans les entrées "syntaxe markdown" mais j'aurais jamais pensé à chercher dans la section "Rédaction" :-)

oui, j'ai vu ton commentaire au dessus. C'est pour ça que je prenais la peine de préciser que c'était encore une proposition supplémentaire.
Cela dit, ta regex est certes plus compacte, mais aussi moins précise !

C'était aussi l'occasion de signaler l'existence des classes de caractères que je trouve sous utilisées.

en utilisant l'option -o (non portable, je ne sais pas si autre chose que GNU grep supporte), et tant qu'on y est, avec encore une autre regex pour le matching :)

$ echo dds[0000]:fhers[080e:0780]dfsgdg| grep -o "\[[[:xdigit:]]\{4\}:[[:xdigit:]]\{4\}\]"
[080e:0780]

(désolé, c'est pas en syntaxe shell, mais les ]] sont interprétés comme des références à wikipedia, mais pas les séquences d'échappement des caractères HTML …)

t'inquiète pas, ça sera ni l'un ni l'autre :D

il datait de quand ce reportage ?

de tête (et sans la moindre idée de ma source), ça a été vrai, mais suite l'amélioration des processus industriels, la quantité d'or a fortement réduit. Du coup, ce n'est plus rentable.

en vrai non, mais en livre, il y en a des très bien.
De tête, "Zodiac" de Neal Stephenson, et "En direct" de Norman Spinrad.
De toute façon, il faut lire tout Spinrad. Allez, hop !

ah chouette ! merci pour la réponse, j'ai appris un truc !

du coup, en prenant en compte le commentaire de Barnabé sur l'évaluation du readlink, il "suffit" de faire ce qu'il faut pour readlink soit évalué à chaque itération au lieu d'être interpréter sur la ligne de commande.

Du coup, on peut aussi s'en tirer avec:

$ mkdir -p dir/link1 dir/link2 dir/link3
$ touch dir/link1/1 dir/link1/2
$ ln -s $(pwd)/dir/link1/* $(pwd)/dir/link2
$ tree dir
dir
├── link1
│   ├── 1
│   └── 2
├── link2
│   ├── 1 -> /home/gab/dir/link1/1
│   └── 2 -> /home/gab/dir/link1/2
└── link3

3 directories, 4 files
$ find $(pwd)/dir/link2 -type l |xargs -I {} bash -c 'ln -s $(readlink -m {}) $(pwd)/dir/link3/'
$ tree dir
dir
├── link1
│   ├── 1
│   └── 2
├── link2
│   ├── 1 -> /home/gab/dir/link1/1
│   └── 2 -> /home/gab/dir/link1/2
└── link3
    ├── 1 -> /home/gab/dir/link1/1
    └── 2 -> /home/gab/dir/link1/2

3 directories, 6 files

le principe de xargs est, justement, de faire ça en boucle.

absolument pas, et même au contraire !

$ seq 1 3
1
2
3
$ seq 1 3 | xargs echo
1 2 3

xargs fabrique une ligne séparée par des espaces à partir d'une liste séparée par des retours chariot et invoque la commande en paramètre avec cette liste. Autrement dit:

ligne1\\nligne2\\ligne3 | xargs command -options [paramètres]

revient au final à

command -options [paramètres] ligne1 ligne2 ligne3

le problème pour ton ln, c'est qu'on voudrait plutôt que ça devienne

command -options ligne1 ligne2 ligne3 [paramètres]

vu que le répertoire cible pour les liens doit être le dernier argument de ln.

A ma connaissance, xargs ne permet pas de préciser à quel endroit de la commande on veut que la liste séparée par des espaces soit injectée (mais j'aimerais bien que quelqu'un me contredise et me montre comment faire !).

Je ne comprend pas bien l'ensemble des détails techniques qui mènent à ce problème, mais c'est lié à une différence entre la taille de la fenêtre qui influe sur le nombre de caractère par ligne, et le nombre de caractères configurés pour le tty.

pour régler ça :

$ # la méthode simple, c'est d'utiliser resize
$ eval $(resize)

$ # on peut aussi utiliser stty en lui donnant le nombre de colonnes. Je ne sais pas trop comment ça se récupère, mais au pire, il y a toujours la bonne vielle méthode dichotomique :-)
$ stty cols <nb cols>

le seul point valide de ton commentaire porte sur le test des codes de retour. Le reste, c'est de la pure convention pour lesquels les deux comportements sont admissibles (sizezof(char) ou pas, et caste de *alloc ou pas).

Sur un extrait de lignes, ça fait un peu court pour en déduire quoi que ce soit sur le professionnalisme de l'auteur du code, non ?

raisonnement dangereux.

Nos responsables politiques ont surement raison de privatiser les services publiques même si nous, utilisateurs, ne voyons pas lequel.
Le monde de la finance a surement raison de spéculer sur les matières premières même si nous, utilisateurs, …

On a fait largement mieux depuis comme langage.

une phrase qui ne veut pas dire grand chose. "mieux" selon quels critères ?
C'est sûr qu'il y a pleins de langages plus adaptés que le shell pour écrire des applications complexes, mais il y a aussi des cas d'usage pour lesquels je n'ai pour l'instant rien trouvé de "mieux" que le shell.

L'analogie pourrie du jour: une perceuse est "mieux" qu'une chignole si on veut percer 10000 trous, mais uand on veut percer un pauvre trou dans une planchette, une chignole, c'est "mieux" qu'une perceuse.

Diaspora aura brûlé beaucoup d'argent pour un résultat… je vous laisse seuls juges

à lire ça, je me dis que c'est dingue comme on a bien été formatés par la culture du résultat …

PS: je viens de visionner la série d'été d'@si (entretiens avec Etienne Chouard, Pierre Rabhi et Franck Lepage), ce qui explique probablement la teneur de ce commentaire.

ça me rappelle une petite anecdote :-)

But then one day, I discovered that someone had blown away the custom emacs profile that I had gotten comfortable with. It took about a week for me to get it restored, and in the meantime, I switched to vi, and got hooked.

Tim O'Reilly — http://oreilly.com/pub/a/oreilly/ask_tim/1999/unix_editor.html

haaaa … ok. je n'avais pas compris le rapport entre le fait que le contenu d'un journal soit affiché sur la page des journaux et sa note.

Je trouve aussi que c'est pas la meilleure idée qui soit. A mon avis (étayé par rien du tout), les journaux dont la note pourraient osciller autour de 0 sont désavantagés, et tombent plus souvent dans le négatif qu'ils ne devraient avec ce système. Ça pourrait être pas mal un seuil avant le déclenchement du masquage (genre -10 ou -15).

on peut faire des blagues sur le viol, tant qu'il n'y a pas de personne violée à portée d'oreille.

c'est pas du tout ça. cf commentaire précédent.

à lire ton commentaire précédent, c'était pas flagrant que toi aussi tu interprétais cette phrase différemment "des benêts et des lâches".
Le fait que tout le monde interprète n'importe quoi n'importe comment ne me paraît pas justifier de détourner l'idée de départ dans une discussion argumentée. Tu peux déplorer que les gens qui s'en réclament explicitement le fasse souvent à tort, mais tu as aussi le droit de présenter ça comme ça au lieu d'utiliser une formulation à l'emporte pièce, qui, du coup, n'éclaire pas vraiment la discussion.

contresens absolu. Desproges ne dit pas qu'il ne faut pas rire d'un accident avec une victime d'un accident. Par contre, rire d'un accident avec un chauffard, c'est plus compliqué.

comme un vrai homme ;-)