Michaël a écrit 2935 commentaires

j'avais codé le pivot de gausse

C'est Gauss.

Ensuite il faudra que tu nous explique ce qu'est une "vraie entreprise".

Microsoft et Unisys par exemple.

Lors de la campagne „We have the way out” en 2002, Microsoft et Unisys voulaient promouvoir les technologies non UNIX… via un site web servi par FreeBSD!

http://news.cnet.com/2100-1001-872266.html

Nous ne les entendons pas depuis la cuisine.

Baisse le son de la télé alors!

Dans ce cas, pourquoi ne pas parler d'egalitarisme ?

Tu ne connais aucun autre exemple de chose dont le nom n'est pas des mieux choisis? C'est comme ça, et il faut vivre avec (ou bien vivre tout seul).

Je suis fan de ton humour.

Nous n'utilisons pas les exceptions. Jamais. Nous ne pouvons pas nous permettre de payer pour exceptions et potentiellement la RTTI qui va avec.

Vous peut-être pas mais le système le fait (bad_alloc). Si vous choisissez d'ignorer délibérement cela, c'est une stratégie parmi d'autres pour (ne pas) gérer les erreurs en C++.

Les exceptions et la RTTI sont des mécanismes indépendants.

Pas d'accord.

Pas d'accord avec quoi? Ton choix es un choix, non?

Tu peux prendre indépendamment n'importe lequel de ces langages…

C'est à dire prendre une décision qui va m'aider à repondre aux questions que je pose sur la déclaration des fonctions.

Ah bah forcément, si tu limites les fonctions du shell à ce qui t'arrange … :-)

Je ne limite rien du tout, je programme le shell comme dans la vraie vie. Par exemple, si tu manipules des fichiers XML ou SGML, tu ne vas pas t'amuser à stocker les représentations intermédiaires dans une variable bash—vu que de toutes façons, écrire une fonction sh qui fasse quoique ce soit sur cette donnée. La manipulation des données complexes est réalisée par des des programmes externes. Si tu n'a pas encore compris ça, tu n'as pas encore compris à quoi sert le shell.

Ben plein de gens ne sont pas d'accord avec toi, sinon la notation $(()) pour faire de l'arithmétique entière n'existerait pas, par exemple

Je suis très content qu'on puisse faire +1 en bash, ce dont je parle dans la citation c'est des données complexes, type document XML, arbre binaire, champ de données. Tout ça est invisible au shell qui se contente d'organiser le flux de données entre les processus.

Donc en gros, tu m'expliques que si je fais des choses plus compliquées que Bash, alors j'ai plus de questions à me poser quant à la façon de concevoir mes fonctions en C++.

Ce que je te dis c'est que dans C++ tu dois gérer la mémoire à la main, pas en shell. Donc si tu programmes en C++ sans te soucier des question mémoires, tu ne sais pas programmer en C++.

Je dis que si tu veux rester au « même niveau » de fonctionnalités que Bash pour les appels de fonction,

Ah bah forcément, si tu limites l'usage du C++ à ce qui t'arrange … :-)

J'ai écrit ça

À la différence de C++ où il faut commencer une psychothérapie à chaque fois qu'on veut définir une fonction

Si tu as décidé entre temps que le contexte était d'écrire une fonction C++ qui fasse la même chose qu'une fonction bash donnée, c'est ton affaire, mais cela ne m'engage pas.

Dans le cas des appels de fonction en C++, je ne vois pas le rapport. Ta fonction se fout de la sémantique de copie. Elle prend des paramètres en entrée, et renvoie éventuellement un résultat, point.

Comment ça la fonction s'en fout? Je ne parle pas de la fonction mais du développeur qui doit écrire le prototype de la fonction. Lui ne s'en fout pas du tout car sinon c'est le SEGFAULT assuré! LA question de la recopie est toujours la question de la possession d'une structure ou non.

Non. Tu fais ce que tu veux en C++. Tu n'es même pas obligé de passer par le système orienté objet si tu n'aimes pas.

OK, mais là on parle de programmation en C++ pas d'un sous-ensemble de C++. Ta proposition de ne pas utiliser les classes est une façon parmi d'autres de choisir une stratégie pour répondre aux questions que je pose.

Si tu programmes sans le côté orienté objet, cela ne va même pas te dispenser de la question des opérateurs de recopie et de la question de propriété d'une valeur transmise par poitneur ou par réfeŕence.

Alors qu'en Bash, c'est tellement mieux : tu es obligé de déclarer une variable extérieure à ta fonction, …

Ta fonction écrit sur stdout ou dans un fichier si c'est une valeur complexe ou renvoie un code de retour. Tu récupères la valeur avec '>' ou avec les backquotes pour les valeur complexes. Le shell ne sert pas à manipuler ces valeurs, il sert à coordonner le travail de plusieurs processus (en leur passant les valeurs).

Ensuite, tu utilises tout un vocabulaire compliqué (« espace de stockage privé » ? Vraiment ?).

Tu peux appeler comme tu veux, mais c'est le retour de std::string::c_str et std::string::data.

Ensuite, n'importe quel codeur C (même pas C++) sait que dès que le type devient un peu complexe, il est préférable (le plus souvent, il y a toujours des exceptions bien entendu) de passer un paramètre par référence (donc par pointeur en C, pointeur ou de préférence référence en C++). Bref, tu as en gros trois choix pour le retour

La différence avec ce que j'ai écrit est que tu as supprimé l'opération de recopie. Si tu passes un pointeur avec transfert de propriété et que tu veux continuer à travailler sur la valeur, il faut la recopier. Quelle que soit la façon dont tu résous le problème, tu n'as pas le droit de le passer sous silence.

[passage des erreurs]
Tu fais comme en C : tu utilises un entier/un enum pour le retour de ta fonction.

Tu as déjà entendu parler de la variable [errno]? En C il n'y a pas de stratégie canonique de gérer les erreurs, en C++ c'est pire.

Tu n'es pas obligé de passer par les exceptions.

C'est une stratégie de réponse aux questions que je pose. En plus elle est mauvaise, parceque des fonctions de la bibliothèque standard lancent des exceptions, et des fonctions d'autres biliothèques peuvent le faire: on ne peut pas complètement ignorer les exceptions. Ensuite si tu veux programmer vaguement sérieusement, tu veux écrire des opérations transactionelles (ta structure est toujours dans un état bien défini où les invariants sont satisfaits).

Tu n'es jamais obligé d'utiliser l'intégralité d'un langage

Travailler avec un sous-ensemble de C++ est une stratégie de réponse aux questions que je pose.

Mais quand on me dit qu'en Bash il est bien plus simple de déclarer des fonctions qu'en C++, je suis très moyennement d'accord.

Tu n'es pas d'accord parceque dans tes explications, tu as complètement perdu de vue le problème de la gestion de la mémoire. Le protocole de gestion de la mémoire fait partie de la définition d'une fonction en C++. C'est une différence fondamentale entre le C++ et des langages de haut niveau ou le shell.

Est-ce que l'utilisation de tableaux est réellement du «bashing» ?

J'ai utilisé ce mot comme titre à un paragraphe qui commence par «comme bash est un gros shell bien gras…» je me suis donc risqué au jeu de mots.

Je sais que l’exagération est voulue,

J'éxagère un peu, mais pas tant que ça!

Pour commencer tu n'as pas déclaré les prototypes de tes fonctions. Ensuite ton exemple est beaucoup trop naïf, quand tu programmes en C++ il faut absolument répondre aux questions suivantes:

1. Comment passer mes arguments à ma fonction? J'ai le choix entre: par valeur immédiate, par référence, par pointeur sans transfert de propriété, par pointeur avec transfert de propriété, par recopie (si mon objet définit un constructeur de recopie, et que celui-ci n'est pas cassé… ah mais au fait, c'est une copie superficielle, etc.) Et encore j'évite les hypothèses de type pointeur sur void avec information adjascente pour récupérer le type (c'est parfois une option sérieuse).

2. Comment récupérer la valeur de ma fonction? Dans un argument que j'aurais moi-même passé en argument (par référence ou par pointeur?) ou bien dans une valeur de retour, ou bien je renvoie une référence ou un pointeur sur un espace de stockage privé?

3. Comment signaler les erreurs?

Et encore je ne pose pas la question de savoir s'il est pertinent de fixer certains arguments comme template alors que c'est une question aprfois importante (par exemple pour les booléens gouvernant les messages de debugging et de profiling).

mais définir une fonction en C++ n'est pas plus difficile que définir une fonction en… C.

Je pense avoir démontré le contraire, puisque C n'a ni référence ni exception, les réponses possibles aux questions précédentes sont limitées à un choix plus restreint. Je parlais de C++ et pas de C, de toutes façons.

Une autre méthode, plus lisible que l'échappement et l'imbrication, consiste à les coller dans une fonction à part.

https://linuxfr.org/users/chat_de_sorciere/journaux/tu-souhaites-apprendre-a-programmer-en-shell#comment-1380013

À la différence de C++ où il faut commencer une psychothérapie à chaque fois qu'on veut définir une fonction, l'introduction de nouvelles fonctions est très facile en shell. Profitons-en pour coder clairement!

Bref : tu as ton opinion sur moi

Heu pour que les choses soit claires: c'est Jehane qui pense que tu fais du mansplaining et je ne m'y associe pas forcément: je me contentais de parler des mansplainer en général.

Entre le mansplaning de Zenitram

Bonjour Jehane, je ne savais pas ce que signifait mansplaining et après avoir lu, je m'étonne que des gens aient relié ce comportement au fait que l'interlocuteur de l'homme en question soit une femme. Je connais quelques hommes (et même une ou deux femmes) qui ont ce trait de caractère, ils sont comme ça avec tout le monde et jusqu'à aujourd'hui je me contentais de les appeler des arrogants prétentieux.

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

Le fait que bash soit nouveau signifie que les scripts shells qui ont été écrits avant que son usage ne se répande n'ont pas été écrits en bash. Cela fait une belle palanquée de programmes à maintenir et développer.

C'est donc bien un travail de compilation classique et tout à fait dans le cœur de cible de make!

Il manque les réponses obiwan kenobi et 42… quel manque de sérieux dans ta méthodologie!

Il y a des tableaux : "$@". Il suffit de faire une fonction pour en avoir

Tu as raison, merci de cette correction!

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

Je profite de cet exemple pour illustrer ce que je disais sur les backquotes.

adirname()
{
   local d
   d=`dirname "$1"`
   (
     cd "$d"; pwd
   )
}

x=`adirname "$fichier"`

À 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.

C'est vrai que ça vision du makefile est intéressante. Aujourd'hui je l'utilise (aussi) pour faire des scènes povray, faire un pdf à partir d'un texte balisé…

Ce sont des travaux de compilation classiques non?

Dès lors, en face à face avec un script sh plus classique, quels seraient les avantages de l'un par rapport à l'autre

La différence est que le Shell occupe une place centrale dans le travail sous Unix, donc si tu décides de travailler de façon adaptée au shell, tu vas reçupérer plein de bénéfices (en termes de flexibilité et d'intégration avec le reste du système)… mais ce n'est malheureusement pas gratuit!

Disons que tu écrives un système pour gérer les livres d'une bibliothèque. Tu vas probablement utiliser une base de données, puis définir des procédures du genre
inserer_livre, enlever_livre, pareil pour les utilsiateurs, rechercher emprunter, reserver, renre, gérer la file des retards, etc. À un moment de ta conception va venir la question de l'interface utilisateur. C'est à ce moment là que tu décides d'intégrer ton travail au shell ou non.

Soit tu décides de caler toutes ces fonctions dans un programme permettant de réaliser les opérations les plus communes.

Soit tu décides de définir une format extérieur pour les types de données les plus important de ton programme ce qui te permet d'écrire chaque fonction citée plus haut comme un programme individuel (tu peux utiliser Python ou ce que tu veux pour cela, et ce n'est même pas obligé d'utiliser le même langage partout!)

La deuxième solution demande un peu plus de travail (surtout parcequ'elle te demande de définir des formats extérieurs). L'avantage est que l'utilisateur de ton programme peut définir ses propres worklfows et y insérer facilement les procédures de son choix avec la langage de son choix.

Je pense que c'est une « rétro-explication »

Dans mon commentaire je n'explique pas à quel point c'est une bonne idée de ne pas avoir de tableaux en shell, mais plutôt que cela fournit un indicateur de la complexité des problèmes que l'on peut utiliser pour décider si le shell doit être utilisé pour ŕesoudre le problème ou non.

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

C'est vrai que j'aurais pu me donner la peine d'être un peu plus clair, merci de souligner ce point!

Toujours sympa d'avoir des références pour ce genre de choses.

Avec plaisir!

Tu peux expliquer pourquoi favoriser la deuxième édition ?

C'est celle que j'ai lue. Comme je le dis, ce genre de livre es souvent substantiellelemnt remanié d'une édition à l'autre et des choses très intéressantes sont parfois remplacées par d'autres, moins intéressantes…

Aussi, pourquoi ce livre est-il sujet à polémique ?

Je pense que c'est parcequ'il souvent approximatif sur les questions techniques. Mais le plus important dans ce livre ce sont les principes généraux de programmation plutôt que les détails techniques. Cela en fait un livre un peu inhabituel car beaucoup de livres se bornent à accumuler des recettes techniques sans vraiment faire de mise en perspective. Ici c'est tout le contraire, si je puis dire!

Apparemment tu partages ma tendance à utiliser l'outil le plus simple qui te permet de faire le travail (car tu préfères apprendre AWK que PERL). Comme bash est un gros shell bien gras, tu peux réfléchir à apprendre sh plutôt que bash. L'avantage est que tu programmeras de façon un peu plus portable — ce qui peut toujours s'avérer utile. Pour la programmation, le gros plus de bash, c'est les tableaux… quelque part j'ai envie de dire que le shell ne sert pas à programmer, mais à décrire un workflow, et que le besoin de tableau témoigne d'un problème qui ne doit pas être résolu dans le shell.

En gros l'idée est que si tu utilises beaucoup ton tableau, il vaut peut-être mieux écrire un petit outle pour résoudre ton problème. Sinon, tu peux très bien le coller dans un fichier, voire dans un dossier.

Ce livre est souvent controversé, mais je te le recommande tout de même: Unix shell programming de Lowell Jay Arthur (2nd édition, c'est important car souvent dans ce genre de livre, les éditions varient substantiellement). Ce livre est très imprégné de la philosophie Unix et si tu le comprends bien tu sais bien à quoi sert le shell. Le point clef est que le shell sert à décrire un workflow et que le programme que tu coordonnes (avec des pipes) doivent travailler sur une représentation commune des données, la plus simple possible. (XML et JSON sont beaucoup trop complexes!)

Exemples:
— onsgmls (James Clark) permet de passer d'un SGML à une version validée et facile à traiter en shell (chaque élément, attribut, etc. apparaît sur sa propre ligne).
— noweb (Norman Ramsey) utilise un format trivial pour pouvoir piper ses données vers un filtre unix donné par l'utilisateur. (Ce qui au passage te fait une source d'exemples de scripts awk.)

Le point clef de la programmation shell est donc la création de programmes élémentaires qui travaillent sur une représentation commune des données, si possible assez simple pour éventuellement être travaillée avec sed, awk, … (cela évite d'avoir à coder des analogue de awk et sed pour la représentation en question).

Les défauts de la plupart des gens:
— sous-utilisation du système de fichiers (le plus simple pour implémenter une table associative est d'utiliser le système de fichiers, Lowell Jay Arthur explique ça très bien).
— sous-utilisation des pipes nommés pour les IPC.
— utilisation de echo lorqu'il faut utiliser printf (echo sert à afficher un message pour l'utilisateur, tout le reste doitr être géré par printf).

Quelques conseils pour se simplifier la vie:
— pour toutes tes interpolations de type backquote un tant soit peu compliquée, écris une fonction auxiliaire: tu éviteras toutes sortes de migraines liées aux échappements et aux quotes!
— cale toutes tes boucles while read dans une fonction à part, cela te simplifiera aussi la vie!

Je me demandais si à part awk et sed, il y avait d'autres utilitaires necéssaire qui sont satellites à bash (dans le meme ordre d'idées que le coreutils)

En gros les thématiques de bases sont:

• fichiers: date (pour les noms horodatés), mv, cp, rm, tar, find, xargs, mktemp ou sa variante qui marche.

• base de données: join, paste, etc. (pour préparer ton input à awk! et trop souvent méconnus)

• filtres: sort, sed, awk, cut, head, tail, grep.

• portabilité: command.

• make

Ensuite viennent les outils correspondant au domaine de ton problème:

• unix: stat, ps, id, /etc/passwd, etc.

• …

Bon courage et amuse-toi bien!

(PS la seconde édition du livre de Lowell Jay Arthur est complètement obsolète — je crois qu'elle parle de System V si bien qu'aucun des exemples du livre ne marche directement, cela fait travailler!)

Je te conseille vivement de t'abonner à comp.unix.shell tu apprendras très vite.

val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
ça serait beaucoup plus fidèle au code..

L'interpréteur fait ce qu'on lui demande. Si tu veux définir une fonction dont la signature est

val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)

c'est possible, il suffit de changer la déclaration

let process_file (f, filename) =
  let ic = open_in filename in
  let answer  = f ic in
    close_in ic;
    answer

comme te l'a déjà fait remarquer Fabrice. Bien que ces deux définitions soient très semblables, il existe une différence dont les conséquences pratiques sont très importantes: il est beaucoup plus facile d'appliquer partiellement la première version que la seconde.

Ainsi, si tu as un traitement f: in_channel -> 'a que tu veux appliquer sur une liste de fichiers l tu peux écrire

List.map (process_file f) l

avec la première version, tandis que la seconde t'oblige à introduire une fonction auxiliaire (on peut choisir une fonction anonyme) ce qui rend le code moins lisible.

Depuis que je travaille dans une boîte qui utilise C++ je suis très malheureux car:
— je redécouvre les charmes des boucles for;
— personne ne sait programmer.

La Charlotte Poulin qui a posté sur bnjourlechat.fr s'est visiblement trompée de site.