gaaaaaAab a écrit 1393 commentaires

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 ;-)

plutôt un appel à un peu de modération.
Évidement, il faut le virer, mais faut pas non plus en faire une jaunisse. C'était une connerie de choisir cette valeur hexa. Ça sent l'erreur de stagiaire ou de mec fatigué qui pète un peu les plombs, qui met n'importe quoi et qui oublie de repasser au propre.
On acquitte que c'était une connerie, on remplace par un truc sérieux, et pis voilà. Il y a p-e des endroits plus adaptés que le source du noyau pour combatte efficacement le sexisme.

ah ok. désolé, l'avait pô compris.

Quand je vois combien de personne viennent aux réunions annuels des syndics de propriétés. Je me dis qu'il y en a qui trouve un peu facile de se défiler en permanence.

J'ai l'impression que ça varie beaucoup selon que le proprio habite ou investisse. (Les proprios habitants participent plus que les investisseurs). Y-a-t-il beaucoup d'investisseurs pour le syndic auquel tu penses ?

Le député n'est pas forcément un local; il n'a pas besoin d'être habitant du coin, et les partis ne se privent pas de les parachuter.

oui, et ?

tout langage est trop permissif :-)

working overtime

je traduirais ça par "heures sup" plutôt que le fait d'être en dehors des plages horaires.

je recommande le livre "Rework" de 37 signals qui est vraiment intéressant à lire.

oui !

Je reformule, j'aurais du dire "zéro doc en tant que tel" plutôt que "zéro doc".

"You should always write your code as if comments didn't exist. This forces you to write your code in the simplest, plainest, most self-documenting way you can humanly come up with."

http://www.codinghorror.com/blog/2008/07/coding-without-comments.html

le commentaire explicite, c'est quand on n'a pas réussi à transmettre tout ce qu'il fallait mettre dans le code. Je trouve l'exemple dans l'article en lien ci dessus très parlant.

ça me rappelle aussi un peu le DOET The_Design_of_Everyday_Things. Je viens de farfouiller sur le net pour me rafraîchir la mémoire. Je pensais au chapitre 3. Knowledge in the Head and in the World". mais vaut mieux le lire in extenso, je trouve le résumé un peu aride.
Appliqué au dev, l'objet qu'en veut concevoir serait le code proprement dit, et le commentaire, le "knowledge in the world". Si on peut s'en passer, c'est mieux.

Le agile manifesto, en essayant de mettre tous les trolls de côté, est une liste de couple de "concepts" opposés. Ensuite, tout est dans la façon dont on équilibre la colonne de gauche et la colonne de droite. Pour certains, le bon équilibre concernant la doc, c'est pas de doc.

voilà j'espère quelques éléments de réflexions. Sur le plan personnel, je commente assez peu, et très très rarement sur des éléments techniques.

Pour finir, la seule documentation vraiment à jour, c'est le code !

gaffe quand même. On va finir par t'appeler CrEv_g ;-)

tout est une question de l'endroit ou tu mets le curseur entre trop de doc et pas de doc. Dans certaines méthodes à Gilles, la règle, c'est zéro commentaire dans le code. (option "Si le code a besoin d'être commenté pour être compris, c'est du mauvais code")

Il faut distinguer la doc interne et la doc d'API à destinations de développeurs tiers. Si getTitle fait partie d'une interface externe, il faut la documenter au moins succinctement (ne serait-ce que pas un lapidaire "self explaining"). Si c'est un bout de doc interne à un module, perso, je ne documenterais pas, parce ce que le développeur qui coincerait déjà à ce niveau là, ce serait pas la peine qu'il regarde plus loin.

En fonction du contexte dans lequel est englobé ce bout de code, les 4 lignes de commentaires seront plus ou moins utiles. J'aurais tendance à dire plutôt moins, mais c'est un exemple un peu caricatural. Les IDEs qui génèrent des getter/setter en profitent parfois pour écrire les 3 lignes de doc qui vont avec.

concernant ton titre, cf mon commentaire plus haut. La doc obsolète, en plus d'être inutile, peut-être nuisible si on ne sait pas qu'elle est obsolète.

un journal bien touffu ma foi.
Concernant la doc, j'ai un peu honte de répondre avec un commentaire bookmark, mais je ne pourrais pas écrire mieux (et même j'en ai compris plus sur le sujet après l'avoir lu qu'avant).

Effets néfastes car quelqu'un de sensé a forcément plus de confiance dans les produits crées par des gens qui savent se tenir, argumenter et s'exprimer sans être grossier ou vulgaire.

mouais … je me considère comme relativement sensé, et à choisir entre l'avis d'un gars qui consacre sa vie à un projet qui le passionne et d'un porte parole d'une multinationale, je ferais plutôt confiance au premier, même s'il est parfois grossier.

Mais je t'accorde que sur ce domaine, je suis un initié. J'ai donc vérifié il y a quelques jours sur les fils de news google (en et fr): l'incident est repris principalement sur des sites de techos. A part un petit article sur 20minutes.fr ou équivalent et un article d'un lecture sur le site du nouvel obs, je n'ai vu aucune reprise dans les media grand public. Dans le Monde, il y a un article qui parle de Torvalds, mais pas de bol, c'est pour le fait qu'il aie remporté le Millenium Prize, qui devrait avoir assez peu d'effets négatifs.

Du coup, l'effet néfaste éventuel, je demande à voir. En tout cas, ça m'étonnerait que la courbe de vente des téléphones sous Android soit beaucoup impactée.

note l'échelle de temps: dans "quelques dizaines d'années", je pense qu'il y aura prescription !

et un journal dans quelques dizaines d'années pour qu'on sache enfin de quel projet il s'agit ? ;-)