Débat suite de Pour en finir avec le bloc "corbeille"

Programmation
#1

[quote=“syam”]Question de performance : les () lancent un sous-shell, c’est à dire un processus supplémentaire. C’est beaucoup plus lourd en ressources qu’en restant dans le même shell, d’autant que shopt est un builtin de bash (il fait partie intégrante de bash, et ne lance aucun processus externe) et ne consomme donc quasiment aucune ressource…

Et accessoirement, c’est plus lisible/compréhensible sans les parenthèses, ça évite d’avoir à se rappeler qu’on lance un sous-shell et donc que les options ne sont pas conservées après la parenthèse fermante (mais ça c’est juste l’opinion personnelle du fainéant que je suis :wink:).[/quote]

Certe, c’est que j’avais l’habitude de faire jusqu’au jour où je suis tombé sur un script dont je ne n’étais pas l’auteur originel et où une option était déjà positionnée par défaut et donc que j’ai désactivé suite à mon instruction… ben la suite du script ne fonctionnait plus !
Et puis, ce n’est pas pour 1 fork d’un petit script que le système va tombé ou que le temps d’exécution d’une seul instruction va en être ressenti. Oui, j’ai mis de l’eau dans mon vin, c’est d’ailleurs pour cela que je n’ai pas lancé le sujet à propos du “ls” utilisé pour tester si le dossier est vide ou non. Les solutions proposées par Watael et moi même sont plus appropriées si l’on va dans ce sens.

edit : je n’avais pas lu l’intervention de Watael à ce propos

#2

Si tu veux mon avis personnel sur cette question, les scripts (shell ou autres) sont inefficaces par nature, ça n’a donc aucune importance (surtout qu’il s’agit d’un script interactif).
Si besoin de performance il y avait réellement, ça serait beaucoup plus pertinent de réécrire tout ça en C ou C++ (ou n’importe quel autre langage compilé) plutôt que de se poser la question de savoir si on peut éviter un fork dans un script shell.

Pourquoi je n’ai pas précisé ça au moment de ma réponse ? Parce que je ne le jugeais pas pertinent pour la discussion, le but était avant tout d’expliquer la différence technique à Ricardo.

Edit : je vois qu’on est d’accord sur le peu d’intérêt d’optimiser sans raison, Totor, là où nos avis divergent c’est sur une question de style d’écriture (ce qui est avant tout une question de goûts personnels et d’habitudes).
Ton exemple est tout à fait valable, mais perso j’aurais utilisé le pattern classique sauvegarde / restauration qui est tout à fait adapté lorsqu’on intervient sur du code étranger, en l’occurrence pour shopt :

OLD_SHOPT="$(shopt -p)" shopt ... ... eval "$OLD_SHOPT"
Je trouve ça beaucoup plus clair à la relecture que d’avoir à retenir tous les symboles cabalistiques de bash, et comme tu peux t’en douter je ne suis pas partisan du code « à la Perl » qu’on écrit une fois mais qu’on ne comprend plus ensuite. Évidemment, le moment précis où ça devient trop obscur pour être compris quelques jours/mois après dépend grandement des personnes et de leur connaissance d’un langage particulier, c’est pour ça que même en C++ (que je maîtrise beaucoup plus que bash) je me force à éviter les constructions ésotériques : je n’écris pas du code que pour moi, mais également pour ceux qui vont le relire.

Bref, encore une fois, c’est juste une question de style personnel…

#3

Bon alors plusieurs choses, à moins que cela ne pose réellement de problème le positionnement des options devrait je trouve être fait au début des fichiers comme c’est fait dans l’énorme majorité des langages. Je n’ai pas encore regardé le script de ricardo pour voir s’il ne valait pas mieux le faire plutôt. Ça permet par exemple de mieux gérer les compatibilités (on trouve plus facilement les options utilisées par le script).

Pour ce qui est de l’usage des sous shell, à utiliser bash autant les limiter autant que possible (c’est comme utiliser la syntaxe ${var%%motif} plutôt que sed (qui est nettement plus flexible). Comme syam, je trouve la syntaxe moche (par contre je ne suis pas d’accord avec son triste avis sur perl). Mais après je ne suis pas sectaire :slightly_smiling:

Je ne suis pas d’accord non plus que si un script shell est trop lent alors il faut utiliser un langage compilé, perl, python et ruby sont d’excellents langages qui ont de très bonnes performances.

Enfin pour les multiples usages de ls, il faudra que je regarde en détail.

#4

Michel, tu as très bien fait de diviser le fil original.
Je reviens à la discussion sur le script de sauvegarde :
Au départ, je voulais plusieurs choses :
M’initier à bash, que je ne connaissais pas du tout et, par la même occasion, me remettre à la programmation, chose que je n’avais plus touchée depuis 20 ans.
Reprendre les bases du tuto que j’avais fait il y a 2 ans (?), qui comme j’ai l’habitude de faire, était destiné à être compris de tous, donc “simple”.
De ce fait, mon idée était d’écrire un script, simple, compréhensible, même de ceux qui, comme moi, ne sont pas “affûtés” pour le codage.
Par la suite, je me suis pris au jeu des perfectionnistes et je suis loin de le regretter, j’ai beaucoup appris et je les en remercie tous.
Toutefois, je pense que les meilleures choses ont une fin et qu’il faut savoir s’y arrêter.
Le script, tel qu’il est fonctionne correctement et même si il est évident que l’on y trouvera encore quelques améliorations possibles, le but initial est atteint et je vais le présenter ainsi dans le wiki.
Ce n’est déjà plus le “truc simple” prévu à l’origine, et je doute fort qu’il soir clair pour beaucoup.
Libre à ceux qui veulent y intervenir de le faire.
Cependant, je préférerais qu’il soit proposé un autre projet, que je m’empresserai de suivre.
Je vais donc modifier ce qui est déjà sur le wiki à cette URL :
http://www.isalo.org/wiki.debian-fr/index.php?title=Script_de_double_sauvegarde_altern%C3%A9e

EDIT :
Je le place aussi sur l’autre fil :

#5

@ricardo > Ça fait un bail que je craignais que tu ne sois écœuré. J’espère réellement que ça ne l’est pas. Ce que je trouverais remarquable c’est que tu continue non pas sur ton script de sauvegarde, mais sur d’autre chose en fonction de tes besoins. thuban, il me semble, adore se concocter des petits scripts pour se simplifier là vie (moi aussi). Je sais que tu ne passe pas ton temps sur la ligne de commande, mais ça peut être agréable une fois dolphin configuré pour le lancer avec un clique droit sur un certain fichiers. :wink:

Quoi qu’il arrive si tu continue et que tu as besoin de conseil n’hésite pas.

#6

Ne te tracasse pas Michel, je vais continuer mais pour ce script, j’arrête là.
Par contre, le wiki déconne, comme d’hab et la transcription est illisible pour le lecteur.
J’ai MP à Lol pour qu’il fasse le nécessaire.

#7

Bonjour,

[quote=“syam”]
Bref, encore une fois, c’est juste une question de style personnel…[/quote]
Oui, tout à fait mais il y a aussi un autre aspect : utiliser les outils fournis par le langage comme je le mentionne ici (le sujet étant “fermé”, je m’auto-quote) :

par ailleurs, si je prends ton exemple de c++, te viendrait-il à l’esprit d’effectuer des appels systèmes pour utiliser des “programmes” externes qui réalisent des fonctionnalités directement disponibles par des objets d’une librairie ?

[quote=“syam”]
…je me force à éviter les constructions ésotériques : je n’écris pas du code que pour moi, mais également pour ceux qui vont le relire.[/quote]
Je suis d’accord mais à mon sens, le problème vient aussi en partie de l’enseignement du développement de script shell qui est pour moi très superficielle et qui est présentée comme un langage limité à lancer des programmes shell. Toutes ses possibilités de manipulation des variables, gestion des processus et jobs, tableaux… ne sont à peine évoqués et donc inconnus. Dès lors, cette syntaxe ésotérique n’est pas connue et l’on utilise ce que l’on nous a appris : la boite à outil constituée de toutes ces commandes (awk, sed, ps, cat …)

enfin, je trouve que l’exemple de sed n’est pas “très” bon. En effet sa syntaxe est pour le moins peut compréhensive et je trouve qu’il s’agit d’utiliser un marteau et un burin pour enfoncer une aiguille dans du beurre (je sais j’exagère :stuck_out_tongue:)

:006

#8

Puisque c’est un débat…

je m’inscris en faux!!!
Le wiki ne déconne pas comme d’habitude… :018 :018 :018

Ricardo à juste oublié une balise… :wink: :mrgreen: :016

EDIT de Ricardo :
Mille Z’excuses Herr Doctor 8)

#9

J’ai pas suivi comment ça c’est fini cette histoire, peut-être que cette ligne ne serait pas trop mal non plus :[ -d dossier ] && ([ -e dossier/* ] && sauvegarde || echo "répertoire vide") || echo "répertoire inexistant"