Michaël a écrit 2935 commentaires

Par contre pour le reste, cela a l'air plus que bien … Merci d'avoir suscité ma curiosité
j'ai peut être trouvé un nouveau jouet.

OCaml est un langage extraordinaire! Les caractéristiques clefs:

• Le typage fort, qui me permet de placer assez d'invariants de mon code dans le système de types pour trouver la plupart de bogues pendant la compilation. En pratique il ne reste plus que les erreurs intelligentes!

• L'aspect fonctionnel. Plus jamais une boule for tu n'écriras! (Mais, bon, si tu aimes bien les variables…☺)

• La simplicité du modèle de compilation. Un bon programmeur C peut estimer facilement la complexité à l'éxécution du code OCaml.

• La relative facilité de lecture! Oui. À côté de Haskell par exemple, OCaml est très facile à lire!

Avec le tant va,
toussant va…

C'est tout aussi clair et sans symbole ésotérique difficile a obtenir sur de l'azerty :)

Je préfère la version qui ne parle pas de f ou de data qui ne véhiculent aucune information sur le programme.

Bien-sûr un exemple de trois lignes n'est pas forcément ce qu'il y a de plus probant, mais en pratique cet opérateur est extraordinairement pratique.

sans symbole ésotérique difficile a obtenir sur de l'azerty :)

Peut-être, mais les maîtres utilisent un clavier QWERTY! ;)

Blague à part, pour la programmation, c'est bien mieux qu'un AZERTY ou un QWERTZ, je n'utilise plus que ça depuis 8 ans, pas question de changer!

Mea culpa, j'ai cru lire $[…].

Un équilibre, en français. Ou mieux, vu la phrase, un compromis. Une balance, ce n'est qu'un instrument qui sert à mesurer la masse.

Merci, le pire c'est que je ne me rends plus compte que j'écris des choses comme ça! Je ne vis plus en France depuis presque six ans et avec le tant qui passe j'ai de plus en plus de sympathie pour Jean-Claude van Damme! ☺

Pourrait-on avoir plus d'info sur ce sujet ?

Une remarque connexe plutôt qu'une vraie réponse: POSIX n'exige de la commande test que de travailler avec un nombre réduit d'arguments (genre 5 ou 6, je ne sais plus) ce qui rend en pratique l'emploi des opérateurs -a et -o impossible si on refuse de sortir du cadre POSIX.

Bonne idee, comme ca il pourra decouvrir PowerShell et se demander pourquoi ces hommes des cavernes s'acharnent a utiliser un outil prehistorique qui n'a aucune structure et qui est si facilement sujet a erreur.

Le shell est lent, vieux et pas simple d'accès. Il a cependant une qualité importante qui met à peu près tout le reste KO: en vertu de son grand âge:

• les méthodologies pour bien l'utiliser sont connues et abondamment documentées
• ses défauts et limitations sont connus et abondamment documentés
• il existe des mégaoctets de scripts shell disponibles sous forme de logiciel libres qui peuvent servir d'inspiration aux débutants.

Pour ce qui est de la comparaison avec le PowerShell je me contenterai d'observer qu'il ne fonctionne pas sur les systèmes d'exploitation qui m'intéressent (FreeBSD, Mac OS X et Debian GNU/Linux). Mais pour ceux qui utilisent des systèmes Microsoft c'est sûrement un outil très utile si cela ressemble au shell. Ceci dit, on peut répondre aux gros trolls velus sans cracher sur ses propres parents!

C'est obsolète et déconseillé, la forme recommandée est d'utiliser $((…)).

On y apprend, par exemple, qu'il est préférable d'utiliser printf au lieu d'echo…

C'est pas comme si la dépêche racontait n'importe quoi! :-)

C'est moyen, comme "règle d'or".

La règles d'or c'est que:

1. Il ne faut pas parser la sortie de ls.
2. Il ne faut pas parser la sortie de ls.
3. Il ne faut pas parser la sortie de ls.
4. Au lieu de ls on peut utiliser le globbing ou find — pas sans discernement, sans que tu le soulignes.

La forme $(ls * 2>/dev/null) par contre est moche, mais pas piégeuse.

Elles est beaucoup plus piégeuse que le globbing ou l'utilisation de find, précisément pour les raisons évoquées ci-dessus.

Je suis tout à fait d'accord avec toi: dès qu'on sort de l'extraction pure de données et qu'on a besoin “ne serait-ce” que d'UNICODE¹ awk montre ses limites. Quand à GNU Awk… pourquoi ne pas utiliser directement Perl? :-) Ce qui est intéressant dans le Awk “de base” c'est qu'il offre une balance très claire entre performance et petite taille d'un côté et expressivité de l'autre. Vu de loin, GAwk est un peu feature bloated — mais a l'immense intérêt d'être un Awk portable — et j'aurais tendance à passer directement à Perl. (Cette position pas hyper subtile n'engage que moi!)

¹ J'ai guillemetté à cause de la taille moyenne d'une bibliothèque supportant UNICODE de façon poussée ou quasi complète.

Cette syntaxe $(…) ne fait pas pour moi partie de la syntaxe sh "originelle".

C'est exact mais la syntaxe $(…) fait partie de POSIX depuis un bon moment maintenant — bien-sûr quand on fait de l'archéologie, on est dans un cas particulier!

In der Tat: GNU parallel is a shell tool for executing jobs in parallel using one or more computers.

Je parlais plutôt de l'intérieur du programme… Est-ce qu'il y a un pipe dans perl qui permettrait de combiner deux fonctions?

printf "Emacs c'est le meilleur éditeur de texte\n" | perl -pe 's/Emacs/Vim/'

C'est inutilement compliqué, on peut simplifier en

printf "Emacs c'est le meilleur éditeur de texte\n"

Sinon juste un petit truc : avant de vous lancer comme des fous dans l'awk, le join paste et consort … il est bien souvent beaucoup plus judicieux d'utiliser des langages plus adaptés comme le python, le ruby le perl (par exemple …)
Même si cela ressemble a un fusil pour tuer les mouches, dans la durée les langages de scripts + une petite base comme sqlite sont plus facile à utiliser, a debugger et à modifier que du shell.
Voire même du fichier ascii a plat comme intermédiaire.

Je trouve que la question suffisamment subtile pour ne pas recevoir une réponse tout à fait tranchée. Bien-sûr utiliser un vrai langage et une vraie base de données a de gros avantages, mais a aussi quelques inconvénients.

L'inconvénient le plus important de cette approche est que cela demande un effort de déboguer les I/O dans la base de données alors que dans la version “zen du shell” il suffit de débrancher un tube pour voir ce qui en sort. De plus l'opérateur de composition de tubes (le |) encourage une structuration très claire du programme et n'a pas toujours d'équivalent dans les autres langages de programmation. (À part bien sûr le |> de OCaml!)

Ceci dit bien connaître OCaml un autre langage comme Python, Perl ou Ruby est bien-sûr un avantage énorme pour développer rapidement des traitements pas encore existants en shell.

Néanmoins, bien connaître awk est tout de même une compétence dont il serait dommage de se passer quand on utilise un système UNIX.

La puissance d'expressivité de awk est surprenante, même avec un niveau intermédiaire on arrive à écrire rapidement des programmes très intéressants et étonnamment courts.

C'est indéniablement un des programmes outil qui, à mon sens, doivent faire partie de la trousse à outil de toute personne utilisant un système UNIX — au même titre que le shell et make.

Excellent complément(s)!

Le shell (quelque soit le shell) n'est pas performant, c'est mou que ça en peu plus (même dash) par conception.

Je confirme totalement, c'est d'ailleurs une raison supplémentaire pour déléguer tous les traitements complexes à des filtres.

Je m'étais amusé à faire de la POO en shell, c'est à dire à implémenter un mécanisme d'héritage. En gros:

• Chaque classe est matérialisée par un dossier
• Chaque méthode est matérialisée par un programme dans ce dossier, typiquement un script ou un vrai binaire natif
• L'héritage et les fonctions virtuelles sont matérialisées par des symlinks.

En appelant copieusement la fonction eval et en regardant sur le dossier plusieurs fois avant chaque appel de méthode, on arrive à faire ramer copieusement n'importe quelle machine!

Est-ce que par hasard tu connais des outils qui vont un pas plus loin et font du parallélisme distribué? Par exemple qui récupère une liste de comptes SSH et lance des programmes sur l'hôte distant?

Rien de dramatique, c'est du chipotage d'inspecteur des travaux finis !

Moi aussi je suis assez loin d'être un expert en DTD mais ça me choque tout autant que toi!

En tant qu'utilisateur de FreeBSD depuis quinze ans comme poste de travail, je ne peux que te dire mon entière satisfaction!

Mon utilisation peut paraître limitée puisque je n'utilise la plupart du temps que trois programmes:

• Emacs
• un terminal
• Seamonkey, le successeur de Netscape et Mozilla.

J'utilise aussi occasionnellement des lecteurs de PDFs et de DJVUs ainsi que des lecteurs audios et vidéos (musicpd et vlc).

Je fais pas mal de virtualisation soit avec les jails soit avec VirtualBox et tout fonctionne très bien, le système (AMD Phenom2 6x/8Go) supporte assez bien les petites montées en charge que je lui fait parfois subir. :D

Côté stabilité je suis super content, j'ai du faire 3–4 kernel panics en 15 ans — mais je l'avais bien cherché.

Il faut par contre assez bien se renseigner avant d'acheter son matériel pour en tirer au mieux parti (notamment les cartes vidéo).

(Ah oui, et puis le système de son est moins byzantin que celui de Linux du coup, il marche mieux.)

Ah oui effectivement, j'ai omis de lire le T ! :-)

Par défaut et depuis Snow Leopard, Mac OS X

Heu, depuis vachement plus tôt!

% mount host:/path/to/export /path/to/local/mounpoint

marchait déjà sur 10.4 et peut-être avant, je ne suis pas archéologue! Cette fonctionnalité était aussi disponible dans le Finder via un truc du type Go To → Connect to server → nfs://host:/path/to/export.

Ah oui, merci pour la correction.

Et y'a un joli © sur toutes les pages ;)

Cela interdit peut-être de le diffuser mais certainement pas de le lire! :-)

Tu confonds -depth avec -maxdepth et -mindepth. L'option -depth demande à find d'explorer l'arborescence de fichiers en profondeur tandisque les deux autres options contrôlent le niveau de récursion.

Au temps pour moi!

Donc une bibliothèque "bullshit-ready" tu veux dire?

Ce que tu dis n'est pas incompatible avec les objectifs du projet, mais ceux qui veulent produire des contenus de qualité sont libres d'essayer. :)

Le projet Blueprint peut redonner de l'intérêt au travail des producteurs de bullshit à l'échelle industrielle, puisqu'il peut leur permettre de préparer leur présentation vaudou avec METAPOST au lieu de PowerPoint. De plus comme METAPOST est programmable, les plus ambitieux pourront produire des pipotrons de qualité qui leur permettra de buller toute la journée au boulot.

Ceux qui ne comprennent rien à cette philosophie sont invités à lire et relire “Devenez beaux riches et intelligents grâce à Excel, Word et PowerPoint” par Rafi Haladjian.