Michaël a écrit 2929 commentaires

existe-t-il des cas où bash est nécessaire ?

Oui, par exemple pour lancer un script bash, c'est-à-dire le cas qui t'intéresse ici.

bash est un interpréteur pour un langage spécifique, qui est différent des autres shells, même si à l'instar des ksh, zsh, dash, fish ou le sh de BSD, il interprète correctement les script écrits pour le shell de Bourne (le /bin/sh historique).

Il y a plein de façon de prouver cette différence, par exemple en comparant les docs où en faisant comme toi une expérience un peu amère. Maintenant que tu as compris l'erreur, c'est le moment de commencer à réparer.

Ben, si tu veux pas t'embêter sur ce genre de détail, lances plutôt ton script en ./script.sh (après l'avoir rendu exécutable), non ?

Le plus simple serait sûrement de se conformer aux instructions du fabriquant, qui donne une ligne de commande à recopier dans le terminal!

pourquoi avoir fait une partition /usr separée,

Tu poses la question dans l'absolu ou dans le cas particulier du PI?

Pour faire du télé travail depuis plus de 4 ans, la productivité est pas aussi bonne, et c'est usant pour le mental. […]

Les communications électroniques sont effectivement beaucoup plus fatigantes (pour l'attention) que les communications orales et elles prennent plus de temps – et puis c'est moins cordial.

Là où je travaille on a un “flex-friday” où on peut travailler d'où on veux, donc ça peut-être au bureau, mais aussi chez soi, chez des amis qu'on va voir pour le weekend (comme ça on peut partir le jeudi soir et paser plus de temps chez eux), efin, où on veut quoi.

Je trouve ça super sympa, ça permet d'éviter la fatigue du trajet (je prends le train les autres jours, c'est pas la mort mais c'est quand-même un peu stressant), de caler ses rendez-vous genre toubib, administration, ou même juste le coiffeur ou faire ses courses à des moments où ces services ne sont pas blindés de monde, et quand on aime bien sa maison c'est super chouette.

Ma situation est donc une situation hybride et je la trouve très agréable. J'ai connu la situation “full-remote” (comme on dit dans le patois d'ici) dans un contexte un peu différent, celui où je faisais la thèse, et quand l'environnement de vie est mélangé à celui du travail, on devient zonzon – en somme c'est aussi sain que si on prenait l'habitude de prendre ses repas dans sa salle de bain!

Alors là, je rigole !!

Un jour où on rit est une belle journée, non? :)

Simplicité …

Simplicité veut dire beaucoup de choses, dans mon propos c'est “simple” comme dans “pas beaucoup d'instructions”. Et puis ça n'a aucune intérêt de pinailler là-dessus, je continue de voir une seule solution plausible postée elle est en awk et elle est courte. C'est tout ce que je veux dire et c'est un simple constat.

L'auteur n'a d'ailleurs pas répondu aux questions de guppy qui avait présenté son aide…

Ce n'est pas une raison pour en tirer des déductions hasardeuses!

je ne prendrais pas ça à la légère

Qui parle de prendre ça à la légère? Ce n'est pas parcequ'une solution utilise un langage plus puissant qu'elle est intrinsèquement meilleure: il y a plein de gens qui n'écrivent pas leurs programmes en OCaml et je peux concevoir qu'ils aient leurs raisons.

c'est juste que de mon point de vue, ce genre de solution convient plus pour dépanner, et que pour le besoin en question

Encore une fois, tout ce dont il est question ici, c'est de faire un traitement bien déterminé une fois sur deux fichiers bien déterminés. On peut appeler ça dépanner ou pas, ça ne change rien à l'affaire. Dans cette situation il est parfaitement légitime d'utiliser “le plus petit programme” qui fait le travail (pas maintenable, pas débogable, pas extensible ne sont ici pas des inconvénients).

Je ne suis le premier à privilégier une solution bien structurée et généralisable si elle semble nécessaire, mais utiliser sed et awk (ou ce qu'on veut d'autre) pour effectuer des traitement uniques sur des fichiers c'est le pain quotidien de l'utilisateur d'Unix que je suis, et je n'ai pas la place dans mon salon pour encadrer et afficher toutes les descriptions de traitement!

C'est certainement utile de connaître awk mais dans le cas présent, la solution donnée répond à un exemple très simple (quelques lignes à traiter) mais ne m'apparaît ni réutilisable ni compréhensible par un non-expert.

L'idée que la solution doit être réutilisable et utilisée sur d'autres fichiers que les deux montrés est inventée par toi.

La solution tient sur 4 lignes, la belle affaire

C'est pas un challenge, c'est une mesure de simplicité.

Encore une fois, ce qu'on peut voir c'est un visiteur paisible et constructif qui a proposé une solution plausible en awk et deux autres visiteurs qui préfèrent pontifier sur ce qu'il faudrait beaucoup mieux utiliser un langage de plus haut niveau, que ce na doit pas bien être compliqué, mais qui se gardent bien de joindre le geste à la parole.

que de bricolages «quick & dirty», le genre de choses que tu utilises quand tu n'as besoin que de faire quelque chose une fois et oublier à jamais

Et qu'est-ce qui te laisse penser que ce n'est pas le cas? L'OP parle de deux fichiers et d'un traitement, rien de plus.

Après, on peut discuter éternellement sur l'adéquation d'un outil à faire quelque chose. Si l'argument c'est simplement que c'est possible, alors oui, mais c'est aussi possible en Brainfuck.

Oui mais personne n'a publié de solution ni en Brainfuck (ça ne suffisait pas l'assembleur) ni en Python ou autre chose et quelqu'un a publié quelque chose qui résout le problème posé, et tient en 4 lignes de awk. Après évidemment qu'un langage de plus haut niveau permet de déboguer ou de faire évoluer le programme. Rien dans le contexte ne laisse penser que ça peut avoir une importance ici, pourtant tu décides de lui en donner.

La question, c'est un peu la même que si tu appelles un plombier pour une fuite. […]

La question c'est une personne qui a une fois besoin de faire un traitement sur deux fichiers bien précis.

Du coup, perl, ruby, python, R, on s'en fout un peu, mais à mon avis il faut changer d'outil.

Donc du coup, les solutions vaporware qui n'existent pas sont mieux que celles proposées?

Quelqu'un qui connaît bien awk s'est donné la peine de prendre 5 minutes pour écrire une solution qui marche et qui tient sur 4 lignes, j'ai un peu du mal à y voir une preuve de l'inadéquation de awk pour faire ce traitement.

Ils veulent publier une forme neutralisée: qui ressemble assez à l'original pour que les experts puissent en évaluer l'authenticité mais qui est assez modifiée pour ne pas être utilisée.

Il doit perdre du temps à expliquer au client pourquoi telle ou telle chose n'est pas souhaitable, lui montrer les incohérence qu'elle produit etc.

“Consacrer” me semble plus judicieux que “perdre”, notamment pour la raison que rendre compte de ses choix techniques devant son client est une manière comme une autre de les mettre à l'épreuve, ce qui créé de la confiance.

Quelqu'un peut m'aider please ?

Oui, qu'est-ce que tu as commencé à faire? Où est-ce que tu coinces? Tu as essayé avec awk?

Exemple de code trop concis :
msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))

Le problème n'est pas la concision, c'est l'imbitabilité. Il y a aussi des formes longues qui sont imbitables, c'est complètement indépendant de la concision.

Un bon exemple de bavardages inutiles est l'utilisation de curseurs pour explorer les structures de données, qui dans de nombreux cas peuvent avantageusement être remplacés par des fonctions d'ordre supérieur. (Dans certains cas, les curseurs sont indispensables, par exemple si l'exploration doit être contrôlée finement, avec des pauses, des reprises, des bifurcations par exemple.) Qu'on juge:

/* Itérateurs à la C++ de la vieille école */
for(x = set.begin(); x != set.end(); ++x){
   cout << x;
}

contre

(* Fonctions d'ordre supérieur, à la OCaml *) 
StringSet.iter set print_endline

La second version est plus claire, car l'intention est directement mise en évidence, alors que dans la première il faut d'abord réduire la boucle for pour comprendre ce qu'elle fait, ce qui est rendu complexe par une variable supplémentaire, le x, qui a disparu dans la seconde version.

Un autre exemple très frappant est l'utilisation du pattern matching, ici pour définir l'évaluation d'expressions booléennes:

type expr =
| Atom of string
| Not of expr
| And of expr * expr
| Or of expr * expr

let rec eval truthtable = function
| Atom(a) -> truthtable a
| Not(a) -> not(eval truhtable a)
| And(a,b) ->  (eval truhtable a) && (eval truhtable b)
| Or(a,b) ->  (eval truhtable a) || (eval truhtable b)

C'est un code très concis, surtout en comparaison de l'équivalent C++ qui demande d'implémenter un visitor pattern sur 2-3 pages pour faire la même chose, et de faire de chaque cas du type une classe à part, ce qui ajouteau bavardage. Sur cet exemple, le code plus court gagne sur toute la ligne: plus facile à écrire, et surtout à lire: l'intention est claire, la vérification est immédiate et la maintenance aisée.

Bien-sûr, on peut aussi utiliser les possibilités d'un langage pour écrire des choses absconses et difficiles à maintenir, mais existe-t-il un seul langage où cela n'est pas possible? Même des langages relativement pauvres en termes d'expressivité, comme le C ou Java par rapport à OCaml, Python ou Javascript, offrent tout ce qu'il faut à un programmeur pour écrire n'importe comment. Roedy Green et ses coauteurs ont d'ailleurs abondamment documenté ces techniques!

Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
- soit vous avez la même chose pour un coût inférieur,
- soit vous avez un périmètre fonctionnel plus étendu pour le même prix.

Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.

Ainsi donc, si on fait l'hypothèse que “le temps de travail utile” contribue soit directement à l'élaboration du produit final, soit à apprendre des choses on conclut qu'on peut réduire les coûts sans sacrifier la qualité sans pour autant arriver à une situation plus enviable pour l'entreprise: c'est le cas où on a rogné sur l'apprentissage.

Ceci dit, je peux passer l'âme tranquille à la suite de mes remarques, encore moins intéressantes que la première:

Technique n°2 — se limiter strictement au cahier des charges

Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.

Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.

Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu “qui fait le job” mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)

Technique n°4 — faire du « test-driven » sur les interfaces

J'ai l'impression que tu cantonnes le “test-driven” aux test unitaires automatiques. C'est un exemple important, mais je trouve l'approche “test-driven” particulièrement utile pour la conception du logiciel, et même dans le cas où on n'automatise pas les tests. Privilégier les tests oblige à concevoir des modules qui ne font pas référence au contexte global de l'application, ils sont donc plus facilement réutilisables. Je trouve aussi particulièrement utile de déléguer tous les accès au système à des classes spécialisées: le reste du code est alors essentiellement pur et peut-être testé avec des classes simulant les appels système (mockup). Cette technique réduit la complexité de mise en œuvre du test et accélère la boucle de développement.

Technique n°6 — Diviser pour mieux régner

Bien souvent les jeunes diplômés (en particulier) ne veulent pas faire de maintenance mais veulent concevoir un logiciel entier. Et lorsqu'il s'agit de reprendre du code, plutôt que le faire évoluer ils préfèrent souvent tout refaire de zéro.

Ils ont bien tort, faire de la maintenance est une des meilleures écoles pour apprendre à programmer simplement et efficacement! (Si on se donne la peine de tirer les leçons de chaque opération de maintenance.)

Technique n°7 — Écrire du code simple

« Ce qui se conçoit bien s'énonce clairement » — Nicolas Boileay-Despréaux.

… et les mots pour le dire viennent aisément!

Souvent les développeurs veulent faire des choses compliquées, et exploiter les fonctionnalités d'un langage au maximum. Mais la réalité c'est qu'un logiciel qui est écrit simplement fonctionne aussi bien qu'un logiciel exploitant toutes les particularités d'un langage.

C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!

PS.: Bon, évidemment c'est de l'humour et donc parfaitement exagéré, mais si c'est drôle, c'est parceque cela éxagère quelques chose de vrai.

Les accolades sont inutiles dans ce cas, ceci est suffisant :

C'est exact, cependant lorsqu'on programme beaucoup en shell, on utilise souvent les modificateurs :?, :-, :+ etc. qui eux nécessitent les accolades, on prend alors l'habitude d'utiliser systématiquement les accolades.

Je sors

Mais non, mais non, c'est sympa. Quelqu'un le fait en APL?

Quelques remarques:

1. Attention à la protection des variables, tout explose si les variables ont plusieurs mots!

[[ "${valeur}" == "${ancienvaleur}" ]]

Et puis quitte à utiliser des mots français, autant accorder l'adjectif, non? :)

1. echo n'est ni robuste ni portable et ne doit être utilisé que pour des messages fixes.

printf '%s,%s\n' "${ancienvaleur}" "${anciencommentaire}"

1. Ton programme a un petit problème d'IFS, il lit le # dans anciencommentaire.

2. Il crée une ligne supplémentaire , au tout début!

En traduisant le code en sh cela devient donc

    sort -nk1 fichier_source | while IFS='# ' read valeur commentaire
    do
      if [ "${valeur}" = "${ancienvaleur}" ]
      then
        newcommentaire="${anciencommentaire},${commentaire}"
      elif [ -n "${ancienvaleur}" ]
        printf '%s,%s\n' "${ancienvaleur}" "${anciencommentaire}"
        newcommentaire="${commentaire}"
      fi
      anciencommentaire="${newcommentaire}"
      ancienvaleur="${valeur}"
    done

(Il y a un petit problème de mathjax dans le bloc de code avec tripe contr'apostrophe, désolé pour le formatage.)

Mon point de vue est que le shell est très bien pour combiner des traitements ensemble mais qu'il est plutôt à éviter pour implémenter ces traitements eux-mêmes. Les raisons sont que le langage rend la description de ces traitements difficile – même si certains dialectes comme bash ou zsh améliorent un peu la situation. Voici donc une procédure awk qui fait le travail, mais beaucoup d'autres langages peuvent être utilisés à sa place:

BEGIN {
    FS=" #"
}

{
    if($1 in seen) {
        origin[$1] = origin[$1] "," $2
    } else {
        origin[$1] = $2
    }
    seen[$1]
}

END {
    for(result in seen){
        printf("%s #%s\n", result, origin[result]);
    }
}

Le cœur du programme est la partie

{
    if($1 in seen) {
        origin[$1] = origin[$1] "," $2
    } else {
        origin[$1] = $2
    }
    seen[$1]
}

qui est appliquée sur toutes les lignes de l'entrée. Les variables $1 et $2 renvoient à la première et deuxième colonne de la ligne en cours de traitement, la déclaration BEGIN { FS=" #" } dit justement comment ces colonnes sont délimitées. La phrase seen[$1] est peut être un peu bizarre, elle correspond à l'ajout d'une clef sans valeur dans un tableau associatif.

Lorsque toutes les lignes ont été traitées, awk* passe au bloc END dont le contenu est lui aussi explicite.

Mais voilà, c'est la vie. Je vais pas en faire une sorte de conclusion générale (et négative) sur le processus de développement dans le logiciel libre, ni me faire une opinion générale (et très négative aussi) sur une équipe de gens que je ne connais simplement pas, encore moins aller la diffuser dans un post.

Oui mais il faut bien reconnaître que c'est toujours plus facile de croire que la source de ses propres problèmes ou déconvenues réside exclusivement dans le comportement et les appréciations des autres! Dans une relation il y a deux personnes (au moins) et si la relation ne se passe pas bien, en l'absence de pathologies, la responsabilité est partagée et c'est aux deux de faire des efforts pour améliorer la relation.

Alors autant pour le libre que pour le proprio, je pense qu'il faut arrêter de balancer sans justifier "c'est des daubes".

Tu as bien raison. Je vais donner un point par logiciel énoncé:

• Microsoft Visual Studio (2009 je crois), PHP Storm: L'interface est bordélique, tout es mélangé sous mes yeux, dans des micro-carrés spécialisés ou des panneaux coulissants dédiés à certains types d'information. L'UI donne l'impression de ne pas être vraiment conçue. Mention spéciale pour PHP Storm qui découpe les commandes de débogage dans deux régions de l'interface.

• MS-Office, l'équivalent Apple: pour le texte, pas de mode plan qui permet de vérifier facilement la cohérence des styles, pour les tableurs pas de mode preuve qui permet de contrôler le contenu des cellules (on peut explorer les cellules une-à-une pour vérifier les formules, mais ce n'est pas ergonomique), impossible d'importer certains CSV (notamment à cause des formats de virgule flottante).

• iMovie: la gestion de la bibliothèque de médias est super lente (ajouter, lister), la préparation des écrans de titre est mal aisée.

• Apple Mali, GMail: l'un comme l'autre ne propose pas de solutions satisfaisantes pour organiser des boîtes avec un gros traffic.

• JIRA: il y a plusieurs genre de vues sur un ticket qui permettent des interactions différentes, du coup difficile de créer des automatismes, l'interface sauvegarde chaque édition, du coup ça rame. Pas de Template de ticket (?). L'édition WYSIWYG est laborieuse (les sticky styles sont mal implémentés). L'API est déguelasse.

Que les libristes soient, non sans raison, attachés à leur terminal, avec un petit côté distinction élitiste, qui le niera ?

Ce n'est pas une distinction élitiste – du genre “eh, t'as vu ce que je sais faire?” – mais juste que, pour certains types de tache, les interfaces texte sont la clef de la productivité! En quelques mots: 1. Les traitements textuels sont faciles à sauvegarder pour reproduire plus tard, j'ai juste besoin de copier les commandes dans un fichier. 2. Ils sont faciles à généraliser, en remplaçant les arguments concrets par des variables. 3. Ils sont faciles à combiner, parcequ'un langage le permet. 4. Il est facile de créer des nouveaux traitements.

C'est possible de programmer des logiciels graphiques qui implémentent 1, 2 et 3 mais je ne connais personnellement aucun exemple de tel logiciel. Sous Mac OS-X il y a l'Automator et la possibilité d'enregistrer les évènements d'une application pour faire 1, 2, et 3 mais je n'ai jamais vraiment beaucoup travaillé avec ces possibilités. Pour 4, l'usage d'un langage symbolique semble essentiellement inévitable!

Deux références que j'aime bien (en anglais):

• http://theody.net/elements.html The Elements Of Style: UNIX As Literature, par Thomas Scoville
• http://marmaro.de/docs/studium/unix-phil/unix-phil.pdf Why the UNIX philosophy still matters, par Markus Schnalke

Mais, d'une part, je trouve que des logiciels ou des interfaces propriétaires qui ont du succès et qui sont discutables en terme d'ergonomie (Twitter, Nextflix), ça existe aussi.

Oui, et pas qu'une. Pour ma part les logiciels propriétaires (connus) avec lesquels j'ai travaillé sont: Microsoft Visual Studio (2009 je crois), PHP Storm, Arc GIS, Garage Band, Ableton Live, MS-Office, l'équivalent Apple, iMovie, Apple Mail, GMail (web), JIRA (web) et dans cette liste si les logiciels de musique et ArcGIS tirent leur épingle du jeu, les autres sont vraiment des daubes en matière d'ergonomie ou de productivité.

Et d'autre part, je suis convaincu que s'il y a un savoir faire en ergonomie, design de fonctionnalité, d'interface, comme c'est le cas en typographie par exemple, je suis également convaincu qu'il y entre une part d'habitude.

Et bien oui, concevoir des interface utilisateur c'est aussi une compétence par soi-même. (Fussent-elles textuelles! Certains logiciels en ligne de commande ont aussi des interfaces toutes pourries – comme docker par exemple.)

Pour en venir au texte que tu cites, parler du logiciel libre comme il le fait, c'est comme parler des entrepreneurs en France: il ne s'agit pas d'un groupe homogène et entre des logiciels libres poussés par des entreprises, poussés par des associations, ou essentiellement personnels, il y suffisamment de différences de buts et de fonctionnement différents que des propositions généralistes comme

En fin de compte, il n’y a pas de secret, c’est comme ça que fonctionnent tous les projets. Il faudrait donc admettre qu’il n’en va pas différemment pour le libre, et faire en sorte que tous les métiers soient intégrés dès le départ pour obtenir un résultat probant.

sont, sans restreindre le genre de projets auxquels on les applique, dénuées de sens. Le texte fait des remarques intéressantes et pourrait sans-doute être amélioré.

Quels shells ?

Comme je suis paresseux, je colle juste une référence vers la réponse très détaillée de Stéphane Chazelas à la question “Why is printf better than echo?" (en anglais donc):

http://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo

mais selon le niveau de la personne, le echo reste plus simple à comprendre.

C'est triste ce que tu penses du niveau des débutants. :)

Blague à part, la multiplicité des point de vue ne peut pas nuire à l'apprentissage, et puis on ne sait pas d'où vient l'OP: il peut très bien être débutant en shell mais un programmeur chevronné avec d'autres outils, il n'y a donc pas de raison de cacher ces détails (un tout petit peu) plus délicats!

Trois remarques:

1. Il vaut presque toujours mieux d'utiliser printf au lieu de echo:

printf '%s\n' "${line}" "ligne_supp1" "ligne_supp2" "ligne_supp3"

Cela évite des mauvaises surprises, si par exemple "${line}" commence par -- ou contient des séquences d'échappement qui, selon le shell utilisé, pourraient être interprétées.
(À la différence de la fonction C, le programme printf applique périodiquement le format pour épuiser ses arguments.)

1. Utilsation de cat inutile:

done < <( cat fichier_origine.txt ) >fichier_final.txt

Que c'est compliqué! On peut écrire

done < fichier_origine.txt > fichier_final.txt

"Ça m'espante, mon daron m'a yave mes chtoumps pendant qu'j'étais parti rayave !"

Ça veut dire quoi (je ne connais que espanter et daron, mais je suppose que yave veut dire chourave?)

Le verbe croaver veut dire croire pour certains enfants, comme par exemple: “Dis, dis, bien vrai que Adrien il croivait que une bille terre ça vaudrait plus qu'une plomb?”