Ignatz Ledebur a écrit 427 commentaires

Merci d'avoir pris le temps de répondre. J'ai téléchargé le manuel PDF du heirloom troff, je vais sûrement l'imprimer pour pouvoir potasser ça à l'occasion.

En tous les cas, j'ai hâte de voir ton projet se monter (aussi bien pour son contenu que pour son mode de publication :).

Peu ou pas, c'est l'idée qui compte. On a bien ici un usage, et non les principes.

Sauf que l'exemple est foireux, parce que l'intérêt du code sous licences dites "BSD" est de pouvoir être relicencié, la seule obligation étant de reconnaître la paternité du code original. Ajouter "pour tous les usages sauf X" ferait d'une telle licence une sorte de copyleft (ça n'aurait aucun sens si cette obligation n'était pas virale).

Que le libre soit une idée recherchée le plus possible, pas de problème, que ce soit un dogme sans réfléchir à ce qu'il y a dessous (genre "je préfère du libre inutilisable au proprio utilisable, juste parce que c'est libre", bof, ça ne mène pas loin)

Et pourtant, c'est typiquement la position des développeurs *BSD. Niveau pilotes ils sont en effet nettement plus intolérants que ceux de Linux, préférant l'ingénierie inverse à la signature de clauses de non-divulgation. Ils font même de très gros efforts pour virer les éléments sous GPL du système de base, jugeant cette licence trop restrictive.

Selon tes critères, ce sont donc de dangereux intégristes de tout premier ordre. Pourtant ils ne revendiquent aucune éthique particulière (rien qui ressemble à celle théorisée et promue par la FSF), et leur code est disponible sous les conditions les plus libérales, si l'on excepte la mise en domaine public.

Bref, rejeter inconditionnellement le proprio ne signifie nullement vouloir empiéter sur la liberté des autres, c'est juste vouloir sanctuariser un mode de production et d'utilisation qu'on estime plus sain (parce que bon, rendre les clients captifs et fourguer des conditions d'utilisation débiles du genre une licence par machine, c'est plutôt côté proprio qu'on voit ça : s'ils ne vendent pas d'éthique, ils sont très fort pour te revendre les droits qu'ils t'ont confisqués dans leur licences moisies).

Sérieux, à chaque fois que tu parles de troff, ça me donne envie de m'y mettre (ce qui n'est pas raisonnable vu le temps qu'il m'a fallu pour être à peu près à l'aise avec LaTeX)… tu as déjà songé à écrire des tutoriels pour maîtriser roff ? vu ton enthousiasme pour ce langage, ça aiderait sûrement à le populariser.

Sinon, quelques questions :

1. comment se passe la cohabitation de heirloom troff avec groff ? j'avais déjà envisagé de remplacer groff par celui-ci, mais sans surprise il plante sur pas mal de pages de manuel (les mdocs en particulier). Il faut donc arriver à faire cohabiter les deux implémentations. Comment tu fais, tu édites ton /usr/lib/man.conf pour le "groffiser" ou tu installes le heirloom dans un path dédié ?
2. comment ça se passe niveau police ? j'avais lu que c'était facile d'utiliser tout un tas de police, mais qu'en est-il vraiment (par exemple je me sers pas mal de Text Companion, c'est facile d'avoir l'équivalent) ?
3. il me semble qu'on ne peut obtenir que du PostScript en sortie, pas du PDF directement. Ça ne dégrade pas trop la sortie "écran" de devoir passer par ps2pdf ? j'imagine qu'on ne peut pas avoir d'hyperliens dans les documents avec ce système…

Et vous, que pensez-vous de l'ergonomie des outils présentés ici ? Y voyez-vous des erreurs grossières ou des améliorations possibles ?

Sans voir le code, c'est difficile. Pour idx, la seule chose que j'aurais à dire, c'est que awk n'est pas vraiment adapté pour faire des commandes, car il n'y a pas de moyen standard de séparer les options de l'interpréteur des options du script (le -Wexec de Gawk). De plus si un jour tu veux ajouter de la recherche de regex donnée en entrée, évaluer et insérer la regex en dur dans le code awk via le shell peut-être bien plus efficace qu'utiliser des regex dynamique en pur awk.

Je t'aurais bien parlé de rlwrap mais il fait pas d'auto complétion et fait 68Kio.

C'est sympa comme concept, je ne connaissais pas. C'est bête cependant, il complète les chemins, mais pas les commandes.

Personnellement je gagne plus de temps avec simplement les abréviation que me permet zsh (Ig va donner "| grep ", Ia -> "| awk ", Is

Et tu emploies ça comment ? tu appuies sur une touche pour expanser (basename $x Ig^A -> basename $x | grep [suite de la frappe…]), ou zsh convertit automatiquement les mots qui correspondent des abréviations (basename $x Ig x$ -> basename $x | grep x$) ? dans la seconde hypothèse, ça ne fait pas trop de conflits entre abréviations et arguments de commande ?

Depuis quand je l'ignore, mais oui, c'est dans la norme.

Allez, donne-moi ce caillou et monte dans la catapulte… ^^

- Cela pourrait être corrigé en virant les '/' en trop à la fin de la variable avant la substitution, et en remplaçant le résultat par / si la substitution retourne une chaîne vide.

Bien sûr, mais ça revient à réimplémenter dirname et basename en shell. À moins vraiment de les utiliser beaucoup dans le script et de ne pas pouvoir traiter tous les chemins en même temps via un tube, il y peu à gagner.

Surtout ces cas d'utilisations ne m'arrive jamais (et je pense que je ne suis pas le seul)

Je ne dis pas que c'est systématique, mais ça m'arrive assez souvent d'avoir des chemins en paramètres, en variables d'environnement (les trucs type "ROOT" ou "TMPDIR"), ou en définition dans un fichier de conf. Dès lors que c'est l'utilisateur qui entre le chemin, tu ne peux rien supposer.

En fait, je pourrais me contenter d'un shell POSIX, mais malheureusement dash n'a pas de complétion, ce qui le rend impropre à une utilisation en shell interactif (on peut néanmoins avoir un historique en le liant à libedit). Mksh à côté propose historique et complétion tout en en étant d'expérience plus rapide et moins gros que bash (avec en prime pas mal d'extensions Korn Shell, comme les tableaux). J'ai jamais essayé (gros flemmard que je suis), mais je pense qu'il n'y aurait pas trop de soucis à l'utiliser en tant que sh en substitut à bash.

J'aime bien aussi le ash de Busybox (on peu compiler juste ça et obtenir un binaire de 80K avec historique et complétion), mais j'ai eu quelques surprises en UTF-8 (j'ai l'impression que ce n'est pas leur priorité). Avec un "set -o utf8-mode", mksh fonctionne au contraire comme un charme.

Donc, pour résumer, mksh me parait un bon compromis quand on cherche juste un shell POSIX quotidien "moderne". :)

Oui, ce serait intéressant. :)

Perso, je teste tous mes scripts avec dash, et j'ai toujours constaté qu'il était plus rapide que bash, ou même mksh (mon shell de prédilection). Après, c'est vrai que côté debug , c'est pas le top, ces rapports d'erreur étant assez sommaires en comparaison de shells plus "évolués".

Pfff… LOL 'portnawak. Rien à voir avec du sexisme. Au lieu d'en chercher où il n'y en a pas elle ferait mieux de s'intéresser aux inégalités de salaires hommes/femmes, ça c'est un vrai sujet.

Debian qui préfère pousser un truc "POSIX" sous licence BSD, qu'un truc GNU sous GPLv3 8-o … c'est la fin des haricots !

S'ils se basent sur la branche Xu, il n'y a pas de guillemets à mettre à POSIX, c'est plutôt en deçà de la norme qu'au delà (ie. si ce n'est pas explicitement requis, ce n'est pas supporté).

Je suis particulièrement sceptique sur ce point puisque les "bashism" permettent souvent d'éviter des appels à sed, awk, expr, ou de faire des choses en beaucoup moins d'Itérations.

C'est faux. Plus il y a d'itérations, plus tu gagnes à utiliser une commande dédiée. Exemple :

#!/bin/sh
while read l; do
    echo "${l%9}"
done

$ time seq 0 9999 | dash bench.sh > /dev/null                                                             
    0m0.11s real     0m0.08s user     0m0.02s system
$ time seq 0 9999 | bash bench.sh >/dev/null
    0m0.45s real     0m0.40s user     0m0.04s system

#!/bin/sh
sed 's/\(.*\)9$/\1/;'

$ time seq 0 9999 | bash /tmp/bench.sh  >/dev/null
    0m0.05s real     0m0.04s user     0m0.00s system
$ time seq 0 9999 | dash /tmp/bench.sh  >/dev/null
    0m0.05s real     0m0.04s user     0m0.00s system

On voit que dash est plus rapide que bash, mais que les deux restent en deçà d'un sed bien placé.

Enfin revenir à du "pur" shell POSIX, me semble pas une bonne approche, je vois cela vraiment comme un simple retour en arrière plutôt qu'une évolution.

Ce n'est pas revenir, c'est rester dans la norme. Honnêtement, les extensions me paraissent plus être des facilités que des réformes du langage. Quand le shell POSIX trouve ses limites (on peut faire beaucoup mais, je le reconnais, pas tout), je préfère coder en Perl qu'utiliser des extensions propres à un shell particulier.

J'ai mis la scène devant un juge, mais ça peut être devant un parterre de journalistes…

De plus, quand en France Pauvert a eu des problèmes parce qu'il éditait les œuvres de Sade, il a pas dit «Ah oui, j'ai bien vu qu'il y avait des trucs assez trash, mais c'était déjà chez l'imprimeur, alors…» Au contraire, il a soutenu que tout le monde avait droit de les lire. Un éditeur endosse pénalement et moralement ce qu'il publie.

Le développement a l'air de s'être fait en coopération avec konami

Quoiqu'il en soit, ça change rien au fait que l'éditeur endosse ce qu'il publie. Je vois mal un éditeur s'en tirer avec un truc du genre, «bon, oui, c'est vrai Votre Honneur : le jeu met en scène un héros blanc de type caucasien au crâne rasé et tatoué de divers motifs celtiques sur 80% de son corps, qui tire presque exclusivement sur des noirs humains de type sub-saharien. C'est certes très malheureux, mais on était tellement à la bourre, vous comprenez…»

Elle parle de Gabriel de Castlevania Lords of Shadow en le prenant pour un jeu japonais : erreur.

Non, elle dit que l'éditeur est japonais. Et comme c'est bien lui qui a la main sur l'aspect final, elle a raison : l'équipe espagnole n'a probablement pas fait le jeu à l'insu du plein gré de Konami, l'aspect final est donc un choix éditorial.

on pourrait faire le même avec les héros de jeux vidéos, qui sont tous musclés et virils. Qu'en conclure ?

Que ces personnages sont à destination des mâles occidentaux. C'est l'objet du troisième volet du dossier intitulé «Genre et Jeu vidéo (3) : Des muscles et des couilles». :)

Pour ceux et celles que ça intéresse il existe également un dossier intéressant sur le sujet en français.

Moi je moinssoie, car qui utilise encore du bourn shell (sh) ?

Personne ou presque, mais ceux qui veulent faire du portable (ou du pas trop non-portable) font du shell POSIX, qui ne propose pas tout ce que bash/ksh/zsh proposent.

À part certains dinosaures crampés à leur HP-UNIX ou AIX qui ne tarderont pas à disparaître
Ou d'autres dans l'embarqué qui le gardent comme shell par défaut, soit par "méchanceté"[…]

Ou parce que pour le prix d'un binaire bash, tu as une p* de Busybox (tu sais le truc qui met toutes les commandes dans un seul binaire).

[…]pour faire des scripts que l'on pourrait très bien faire en bash ou zsh.

Et voilà bien le problème, comme tu les dis en post-scriptum c'est bash ou zsh. Les développeurs bash/zsh/ksh n'ont pas tous fait les même choix en terme d'extension. À l'inverse, bash exécuté en tant que sh doit se comporter en shell POSIX, idem pour zsh, idem pour ksh.

(je te plussoie/redéplioie parce qu'au fond c'est ton opinion… et que je ne moinse jamais personne… ;)

"dirname" "basename", c'est tout de même beaucoup plus court et performant en bash (pas de fork pour lancer un binaire extérieur "à la con") :

Sauf qu'il faut que tu sois sûr de la tête du chemin en argument. Exemple :

#!/bin/sh
echo "-- Built-in --"
echo "dirname  [${1%/*}]"
echo "basename [${1##*/}]"
echo ""
echo "-- Commandes --"
echo "dirname  [$(dirname "$1")]"
echo "basename [$(basename "$1")]"

$ ./dir.sh ../toto/
-- Built-in --
dirname  [../toto]
basename []

-- Commandes --
dirname  [..]
basename [toto]

$ ./dir.sh /lib                                 
-- Built-in --
dirname  []
basename [lib]

-- Commandes --
dirname  [/]
basename [lib]

$ ./dir.sh /
-- Built-in --
dirname  []
basename []

-- Commandes --
dirname  [/]
basename [/]

Si je fais la commande que j'ai montrée plus loin, dans certains cas je vais travailler dans mon ~. Si le dossier cible est censé être temporaire dans le script… ^_^'

De plus, j'ai eu quelques surprise avec les regex internes. Je me disais aussi que c'était beaucoup plus rapide (je stockais une immense chaine avec toutes les données, dont j'éliminais/récupérais certains éléments à coup de regex), et bien non, pour les gros trucs sed semble faire du meilleur boulot.

À noter que, il me semble, ta proposition explose si dirname $fichier contient des espaces. C'est beaucoup plus facile d'écrire des backquotes expansions robustes en les isolant dans des petites procédures.

Non, $fichier est entre guillemets, donc dirname fonctionne, lui même entre guillemets, qui permet à cd de fonctionner.

Par contre, la dernière parenthèse fermante est de trop. :)

Et les guillemets qui entourent l'expression de premier niveau sont inutiles (je les mets par tic, car avec "local x=$()" il les faut absolument si l'expansion retourne plusieurs mots).

Je pense que c'est une « rétro-explication », bourne shell était trop limité pour gérer les tableaux et on a trouvé une explication un peu moins pittoresque pour l'expliquer.

Il y a des tableaux : "$@". Il suffit de faire une fonction pour en avoir. Le soucis c'est plutôt le découpage des mots… Perso, j'essaie de caler la constitution et le traitement du tableau dans awk quand j'en ai vraiment besoin…

Je pense qu'il est important de parler de bourn shell plutôt que de « sh ».

En fait, non. Le Bourne shell contenait plein de choses obsolètes. Aujourd'hui il vaut mieux parler de shell POSIX. Le meilleur shell pour s'y initier est ÀMHA dash (« branche Xu », la branche Debian est différente).

Le bourne shell quand je ne connais pas la configuration cible (mais dans ce cas il est important de vérifier les usages que l'on a des outils tel que grep, cut et sed qui contiennent une foule d'extensions GNU, on perd tout l'intérêt d'utiliser un shell POSIX.

Tout à fait, ça n'a pas de sens d'écrire du shell POSIX si les commandes ne suivent pas. La norme est d'ailleurs publique.

Bon après, il y a aussi des trucs qui ne sont pas dedans, mais présents partout ou presque: "local" (le gros manque, selon moi), "find -(min|max)depth", …

Il me semble que même avec POSIX les $() sont accepté

Oui. D'ailleurs, je trouve la syntaxe bien meilleure, puisque c'est bien la sortie d'un sous-shell qu'on récupère et pas d'une commande. Ainsi, on peut écrire un truc du genre (pour récupérer le chemin absolu du dossier contenant un fichier) :

x="$(cd "$(dirname "$fichier")"; pwd))"

je vient d'avoir la réponse que je cherchai, c'est stable ci long ne fais pas trop de mélange a ma sauce sans parler de java.

Si tu ne fais qu'ajouter des briques, il ne devrait y avoir aucun soucis. Par contre, si tu remplaces certaines pièces fournies en standard, comme partout ça risque fortement de casser à un moment ou à un autre.

Comme tous les systèmes de notation que je connais, celui de LinuxFR est inique et inepte.

Après, il répond à un besoin assez légitime, qui est la hiérarchisation des contenus en nombres. La politique éditoriale du site en la matière est de laisser cela à la masse des contributeurs fidèles (puisque plus on poste dans la ligne, plus on gagne en capacité à noter et plus on renforce la ligne). C'est un critère moisi qui en vaut d'autres (genre laisser ce soin à une petite équipe éclairée).

Maintenant, c'est vrai que je me demande ce que ça donnerait si les notes devenaient invisibles. Parce que j'ai quand même l'impression que leur publicité constitue un certain facteur d'agressivité dans les débats (pour celui qui se sent réprouvé comme pour celui qui est au contraire galvanisé)…

Il refusait quasiment toute apparition audiovisuelle, toute interview.

Il en a accordé une assez longue à Libé en 2003, pour ceux qui veulent en savoir plus sur le bonhomme.

Si les blancs n'étaient pas presque 6 fois plus nombreux, peut-être… ;)

Resterait cependant la minorité en terme de poids politique et économique (pour des raisons historiques qui s'expliquent sans trop de difficultés).

Aux USA, les noirs ne sont pas minoritaires.

Euh… si, un peu quand même.

Je me demande bien comment va réagir Patrick Volkerding face à systemd.

Ça restera hors de Slack, sauf si la maintenance devient trop problématique (genre ça pète dans tous les coins parce que tout est codé avec systemd en tête).

On verra, mais déjà à présent, pour avoir les sources d'udev il faut télécharger systemd…