Pour moi il est important de mettre ces constantes en haut du fichier car c’est plus rapide pour les modifier et si quelqu’un d’autre utilise le script il n’a pas besoin de comprendre ce qui ce passe pour changer les paramètres :)
Complètement du même avis. Ces variables permettent de configurer le script. Il y a tout intérêt à ce que celles-ci soient visibles et facilement accessibles. On peut facilement se retrouver face à un script composé d'une centaine de lignes. Et là bonjour pour retrouver LA variable à modifier qui nous intéresse. De plus, en positionnant ces variables en début de script, on annonce clairement les variables qui sont modifiables par un dev "client" du script. Au delà de ces variables, c'est "touche pas à ca".
Je fais pareil à une exception. En haut ce sont les variables générales du script. Dans les fonctions ne se trouvent que les variables qui ne seront utilisées que localement.
J'adore ton style ultra chill dans tes tutos ^^. J'apprends plein de choses, j'approfondis mes connaissances et en plus je kiff la musique d'ambience ^^.
Perso ça ne me gêne pas du tout le retour à la ligne avant `then`. Aussi, on peut utiliser le tiret normal au lieu du tiret bas pour le nom des fonctions (mais pas pour le nom des variables).
bonjour, pour les fonction je conseille a mes stagiaires qu'elle porte un nom avec le même préfixe style : func_create_archive_filename pour ton exemple. cela permet dans de gros script quand la fonction est appelée après plusieurs dizaine voir centaine de ligne de savoir quand on voit "func_create_archive_filename" que c'est bien un appel de fonction. et pour les variable je leur dis toujours de les protéger avec des double quotes surtout dans les tests mono crochet. ( votre maman vous a toujours dis de vous protéger ). merci pour cette vidéo.
J'ai découvert ta chaîne par mon frère récemment, c'est vraiment du lourd ! Ton format vidéo quand tu expliques avec le terminal me rappelle mes années "piscine" à l'école :p 14:25 Ou "backup_folderlist" sinon ;)
Propre, tu m'as donné envie de faire du bash plus en profondeur avec des scripts au lieu de taper 1 à 1 des commandes dans le terminal comme j'ai l'habitude de faire
Pour le coup je suis pas tout à fait d'accord quand tu déclare les constantes type folders_to_backup directement dans le main à la fin du fichier Pour ce genre de variables, le laisser en haut permet de les utiliser comme un "fichier de configuration" et ça évite de devoir descendre dans le main pour parametrer le truc
Trés intéressant , merci . Ta logique est vraiment solide meme si elle chagrine certain (plutôt les feignasses de mon points de vu , c est de bonne augure ).
C'est un truc qui me rend ouf, mais rien de bien grave mais quand même. Expliquer une syntaxe, c'est expliquer *comment* elle va être interprétée et *pourquoi* 😗
Très intéressant. Je partage la même vision du code: de petites fonctions qui font bien ce qu'elles annoncent, et seulement ce qu'elles annoncent. Bref du code auto-documenté (self-describe).
Salut, Je ne suis pas totalement d'accord avec tout ceci. Niveau commentaire, pour moi c'est indispensable, surtout dans des très gros scripts, savoir que tel fonction utilise tel variable, quel a besoin de tel paramètre, ou inversement en un seul coup d'œil, c'est top. Après un commentaire qui indique la même chose que le nom de la variable n'a effectivement pas d'intérêts. Niveau art plastique ^^, je trouve que c'est pratique pour séparer le script en block, j'utilise personnellement beaucoup ceci pour des gros scripts encore une fois, avec une balise début et fin. Pour les variables, globalement d'accord, sauf pour ces deux variables, qui sont susceptibles d'être changé. Dans ce cas, au début du script c'est le plus adapté, encore une fois si le script est conséquent. Avec même un petit commentaire pour dire de séparer par un espace les répertoires a sauvegarder. Je rajouterai un autre truc indispensable, des tests, vérifier le bon format des variables, si tout c'est bien passé, afficher des vrais infos, parser les erreurs etc .... Un script doit contenir le maximum d'information, que ce soit en commentaire, qu'en logs. Cela n'enlève rien à la qualité de tes vidéos.
Salut Xa Taz ! Pour les commentaires je suis d'accord avec toi, ma critique était effectivement plus adressée aux commentaires redondants. Pour l'art plastique c'est peut-être plus une question de préférence, j'aime avoir le minimum de sauts de lignes pour avoir plus de code dans un meme écran mais je peux comprendre que ton coté ASCII artiste te démange de temps en temps :p J'ai peut être paru un peu extreme dans la video mais je te rejoins aussi pour les constantes qui sont plus pratique en début de fichier. Je pense que j'aurais pu plus insiter sur le fait de penser à si il y a une raison de placer ses variables à un endroit. Si plusieurs variables n'ont rien a voir les unes avec les autres et n'on pas vocation a être modifiées souvent, alors il est plus logique de les mettre proche de là ou elles sont utilisés pour facilité la comprehension. Je te rejoins également pour les tests et les messages d'erreur. Merci d'avoir partagé ton experience ;)
Hello, Merci je m'initie à bash à votre video m'a bien aidé , en 16:30 j'ai appris bien plus de choses qu'après avoir passé des heures sur d'autres sites à me prendre la tête; Ceci étant , timecode 4:36 vous dites"si je prends une variable qui n'existe pas, ça me dit qu'elle est non vide ? après vérif il apparaît qu'elle est vide... et vous poursuivez en disant que xyz a été interprété comme une chaine de caractère alors qu'en fait c'était une variable" !!!! Là je ne vous suis plus , c'est une variable ou pas , ce n'est pas une variable car pour ma part elle n'a jamais été initialisée dans votre exemple; Merci de votre retour Sarah
Salut Sarah ! En bash il n’y a pas de types pour les variables contrairement au autres languages. Donc toutes les variables sont des chaînes de caractères. ( même les nombres)
Merci pas sûr d'avoir tout pipé notamment à 5:15 [[ -n $adawd......]] ça ne décrit rien parce que cette variable existe ??? alors pourquoi est ce que ça ne décrit rien comme vous le dites ? c'est illogique par rapport à votre réponse qui précise que toutes les variables sont des chaines de caractères , alors si c'est le cas ça devrait afficher non vide n'est ce pas ? Merci Sarah
Vidéo très sympa. Le bash (shell) étant un langage très vieux, est-ce toujours un bon point d’entrée pour apprendre à coder? Je pense qu’on peut considérer ta manière de faire comme de la programmation fonctionnelle non?? Merci
Salut Soufian, je pense que c'est très mauvais point d'entré pour apprendre a coder car il y a plein de chose manquante et de "hack" qui donne de très mauvaise habitudes. Mais oui on peu un peu considerer ca comme de la programmation fonctionnelle
@@cocadmin non, ce n'est pas encore de la programmation fonctionnelle, car il y à des états internes qui modifient le fonctionnement des fonctions appellées (l'état est ici stocké dans des variables, et changerait le fonctionnement d un même appel de fonction fait à des moments différents, selon l état de ces variables). En fonctionnel, un appel à une fonction se fait avec un jeu de paramètrs (des "arguments"), et appeler une fonction avec les mêmes arguments dois toujours donner le même résultat, quel que soit les opérations faites avant. Ici l appel dépendra de l'état interne du script et même de la fonction. Il faudrait virer toutes les définitions de variables et les remplacer par des arguments aux fonctions (je simplifie bcp trop, c'est un peu difficile à résumer en quelques lignes). En fait, en général en script shell il est difficile d être 100% en programmation fonctionnelle, car on va modifier l état de quelque-chose (et plein de variables (IFS, etc) peuvent même modifier le comportement même si le script lui-même ne les contient pas!). Mais on peut quand même s en approcher (comme ici, ou la factorisation du code effectuée le rapprochera de la programmation fonctionnelle).
@@cocadmin Par contre c'est une belle "factorisation" du code. Le script final est devenu beaucoup plus lisible et facile à comprendre et modifier. (Même si il est devenu malheureusement buggé car le renommage des variables n'à pas été fait partout!).
Bonjour Cocadmin ! Depuis quelques mois je me suis mis à faire mes scripts bash pour automatiser des tâches redondantes, je gagne un temps considérable. J'essaie continuellement d'améliorer mon code en faisant des recherches et avec tes vidéos ma compréhension de bash est beaucoup plus clair, merci pour ton partage. Cela dit, à 15:41 de ta vidéo, tu mets ta fonction "main" en commentaire et appelle la fonction "print_start_status_message" et j'avoue que je ne comprends pas bien l'utilité de la manoeuvre...?
Salut, pour ma part j'aurais ajouté des vérification de l'existence des chemins et des fichiers. Suivant la machine source j'aurais plutot fait tar sur celle-ci, envoyé sur la destination par rsync (l'archive ou les fichiers) et vérifié l'état a l'arrivée. Je suis peut être un peu parano du réseau et ses coupures ^^
Je pense que la raison pour laquelle on met les variables au dessus ,est d'avoir un aperçu rapide ou faire un changement plus rapide du code..surtout quand t'as +300 lignes. pas besoin de lire tout le code pour trouver les variables...chacun sa methode
Pour les constantes je suis d' accord. Pour les variables un peu moins. Mais effectivement en script bash on a souvent plus de constantes comme des chemins de fichiers etc
J'aurais plutôt nommé la méthode "create_archive_filename" en get_archive_filename qui aurait renvoyé une valeur et utilisé cette valeur pour initialiser une variable déclarée dans le main. Une méthode qui crée une variable, je ne trouve pas ca très élégant :)
Une variable peut être modifiée après sa créations alors qu’une constante a une valeur assigné à sa création que l’on ne voudra jamais changer par la suite dans notre code. (Comme par exemple le chemin d’un fichier)
Un piege dans lequel je tombe trop souvent : quand une variable (souvent en argument de script) est un chemin de fichier/dossier, et que ce chemin contient un espace. Si cette variable n'est pas protegee avec des guillemets quand elle est utilise dans une sous-commande, KABOOM. Le pire c'est que parfois le script semble parfaitement marcher, sauf qu'en fait la ou les sous-commandes ont juste fonctionnees avec plusieurs arguments ou lieu de juste un pour ce chemin de fichier... Ca donne souvent des surprise du style nom de fichiers/dossiers partiels qui ont ete cree :D
Aïe ouai .. Pour éviter ca tu peux rajouter un peu de validation au debut de ton script/fonction et déclencher une erreur si il n'y a pas le bon nombre d'argument.
11:46 pour le coût je ne pense pas qu'il était nécessaire ici de faire une fonction pour remplacer une seule ligne, par contre un commentaire pour expliquer l'utilisation des paramètres pour qu'on ne soit pas obligé d'aller lire le man aurait été pas mal
slt. moi j'ai un souci avec virtualbox sur manjaro. il ne me fait pas voir mon DD externe depuis l'explorateur virtualbox quand je veut créer / chercher ma VM .vdi sur le DD externe. et aussi bien une clé usb. une idée ??
Je me souviens que dans VMware il y avais un paramètre pour que un appareil usb se branche directement dans la vm. Peut être que tu peux chercher « usb pass through virtualbox Linux »
Salut, je découvre et j'enchaîne tes vidéos. Pas tout vu, tu en parles peut être ailleurs, je me demandais si tu remontais tes modifs pour partager. Sûr que les scripts ne sont pas parfais, mais ils sont fonctionnels et partagés. Le collaboratif via l'amélioration étant dans l'essence de l'open source, je me posai la question ;) Signé : Un barbu
Salut cocadmin On peut donc faire des fonctions à tire-larigot sans que ça pose problème ? En tout cas c’est fou tout ce que je vais pouvoir améliorer sur mes scripts bash grâce à quelques vidéos que je viens de regarder c’est top et je t’en remercie !
attention quand même, il y a plusieurs oublis et erreurs dans la vidéo : - les variables ne sont initialisées que dans la fonction main, et donc main **doit** être appelée en fin de script, même si vous ne voulez tester qu'une seule sous-fonction. Il faut donc laisser le main final mais plutôt commenter, dans la fonction main, les lignes qu'on ne veut pas exécuter cette fois là pour notre test. Sachant que la aussi certaines lignes (l appel à la fonction de nommage du fichier, par ex) peuvent être indispensables pour tester les lignes suivantes. - De plus il à renommé (de belle façon) certaines variables... mais ne l'à fait qu'à un seul endroit! Cela à introduit des bugs: aux autres endroits il n'appèle pas le $nouveau_nom mais $ancien_nom (qui est du coup non défini, et donc retournera une chaîne vide). Il faut renommer partout! - et un petit avertissement avant de nommer ou renommer des choses : il faut faire attention aux parties de noms communes: si vous avez une variable nommée "foo", et une autre nommée "vlah_foo_blah" (ou même n'importe quoi dans le script contenant la sous-chaîne "foo") : si vous voulez ensuite juste renommer la variable "foo", vous ne pouvez pas simplement lancer un chercher/remplacer global de "foo" en "bar" car ça modifiera aussi tous les autres endroits contenant "foo", et pas seulement ceux correspondant exactement à la variable "foo". (pour ce dernier soucis, il faut donc choisir des noms bien distincts les uns des autres pour les variables, et donc eviter en général d'avoir une variable dont le nom est contenu entièrement dans un autre nom de variable (ou commentaire ou valeur). Dans la vidéo il à plutôt bien renommé ses variables! (mais à malheureusement oublié de les renommer partout).
Je suis débutant sur linux et a 9:25 tu dit que c'est pas des files mais des folders, j'ai cru comprendre que tout est fichier dans linux, c'est peut-être dans cette idée que la personne a décidé de mettre backup_files !!
Top comme vidéo. Seul truc que j'aurais à redire c'est la création de fonction pas forcément utile: en soit, le script s'exécute, les fonctions ne sont pas exportées ou dupliquées, du coup est-il vraiment intéressant de tout mettre dans des fonctions ?
Bonne question! Ce n'est pas juste pour la clarté mais c'est effectivement pour pouvoir plus facilement les exporter dans un fichier different et c'est aussi une bonne pratique de programmation en general parce que ca permet de pouvoir tester ton code. C'est très facile de faire des tests unitaires sur des petites fonctions indépendantes mais c'est presque impossible d'en faire sur un gros morceau de code qui fait plein de choses a la fois.
$dest n'existe pas ! => c'est $backup_destination !!!!! $backup_files non plus => c'est $folders_to_backup !!!! Quand on modifie les noms des variables, il faut penser à changer partout ;-)
y'a quand meme un non sens : tu mets les variables en bas mais tu ne les utilises qu'au dessus puisque tes fonctions n'ont aucun parametres, c'est un peu pete pour l'argument de mettre les variables la ou elle sont utilisées ;)
😂 .. j'attendais de le voir ce commentaire. J'attendais aussi à ce qu'il montre une astuce ou bonne pratique sur les paramètres à passer en fonction.. Mais bon .. en même temps quand tu vois 2 fonctions qui font juste un écho.. 😅 tu comprend que c'est juste pour l'exemple 😉 J'ai réussi à placer mon com ! Yes !
Salut ! J'aime bien tes vidéos, je viens d'en enchaîner quelques unes. Par contre, petite remarque concernant les fonctions. Je ne vois absolument pas l'intérêt de les utiliser si elles ne contiennent que des variables globales. Dans l'exemple de cette vidéo, on ne peut pas tester la fonction qui fait le tar juste en remplaçant "main" par "backup_files" par exemple. Du coup, quand c'est fait comme ça, tout l'intérêt des fonctions est perdu. Je pense qu'une fonction ne devrait utiliser que des variables locales et prendre des arguments, et là, en effet, on peut tester une fonction et ça a un intérêt (en plus d'être utilisable dans n'importe quel autre script indépendamment du nom des variables du script qui l'appelle). Perso, si les fonctions ne sont pas indépendantes du script et de ses variables, ben je trouve que les utiliser, ça complique les choses. Et un script écrit proprement avec des noms de variables clairs est mieux.
9:25 Techniquement faux ! 😇 Sur Linux, la philosophie est : « Tout est fichier », ce qui donne naissance à /proc 🙂 L'important reste *la volonté*, tout dépend à qui tu souhaites parler.
Créer des fonctions sans utiliser les paramètres (de fonction) et se reposer sur les variables globales est quand même bof… Aussi, on mets toujours les constantes en haut de fichier, pas pour faire beau mais pour, en cas de modification, les trouver très rapidement … Un collègue Devops …
C'est des scripts grand public, les gens ont pas que ça à foutre que de chercher dans tout le code si y'a des variables à changer et ou est-ce qu'elles sont, c'est pour ça que la règle tacite est de mettre les variables qui doivent être changées au tout début.
Je fais pas beaucoup de prog, je sais pas si mon avis est important. Mais si un de mes apprenti me montre un script ou les var et constante de "configuration" sont pas au début et que je dois me casser le cul a trouver ou elles sont ces var, il risque de recommencer. faut arrêter de vouloir péter plus haut que sont cul sous prétexte d'être SYSADMIN.
Tu fait partis de ceux qui font des unit tests en bash :) Felicitations ! De ce que j'ai remarqué a premiere vue c'est surtout des inconsistances de style dans la manière dont tu declares les fonctions (mot clef function et parentheses sont parfois utilisé, parfois non ) et dans ton indentation. Je le garde au chaud pour critiquer plus tard ;)
Pas de shebang dans le script hspot, de l'art plastique à tout va dans le script hspot (des sauts de lignes en plus, d'autres manquants), un manque de consistance important, des tests qui dépendent uniquement de si le script est en mode strict, du shebang en /bin/bash sans env, des tests unitaires avec des sleep partout (incluant des décimales), une compatibilité avec différentes versions bash douteuse. C'est la difficulté avec Bash, un langage "batard" qui fonctionne de 1000 façons ... Trouver la façons homogène n'est pas chose aisée. Tu sembles t'être lancé dans une sacrée aventure !
@@o_be_one merci beaucoup 😃 c'est vraiment constructif ... Bon si j'ai pas mis le shebang c'est pour faire un fichier de configuration comme ça on peut activé des modules depuis le beehive (je me suis un peut inspirer des fichers config sous linux ) bon je pensais que c'était une bonne chose a faire 😊
C'est un résumé rapide, mais si ça peut t'aider ça me fait plaisir ^^. J'avais peur d'être trop négatif dans mon message ... Je ne fais pas tant l'effort de faire mes scripts rigoureusement propre non plus. hspot te paraît juste un fichier de configuration mais il contient du script, et pour cette raison c'est important de respecter la norme si tu veux être sûr que ça roule correctement partout (pas tout le monde utilise bash par défaut, par exemple c'est presque certain que quelqu'un sous ZSH voit le script crasher si il ne tape pas "bash hspot" ; ce sera aussi un problème que tu risques de rencontrer en mettant ça en tâche cron par exemple ; et la je dirai d'utiliser "#! /usr/bin/env bash" plutot que juste "/bin/bash"). Aussi selon le lien de cocadmin dans un autre commentaire (google.github.io/styleguide/shell.xml), Google considère OK de faire un script sans extension si il s'agit du script principal qui démarre les autres. Après les autres, les "modules", devrait contenir une extension. Il existe une forme de "combat" entre .sh ou .bash ... Je fais parti de l'école .bash, mais c'est une question de préférence au final. Je vois aussi de l'inconsistance dans hspot avec les [ ] et [[ ]]. Personnellement comme cocadmin je recommanderai les [[ ]] comme le choix par défaut, ça t'évitera bien des problèmes et le fait de ne pas mixer les 2 te facilitera la lecture. Y a beaucoup de raccourcis, tu sembles avoir soit une bonne expérience soit des connaissances plutôt large dans le scripting bash (pour être franc on dirait même que c'est des morceaux de scripts assemblés ci et là tellement y a de différences). Passe sur le Discord si tu n'y es pas déjà et fait signe si fais des mises à jour et souhaite avoir d'autres avis ^^ !
@@cocadmin voire plutot éviter carrément d'utiliser bash :-) il existe fort heureusement une multitude de shells suivant l'esprit Bourne ou l'esprit Joy pour ma part j'aime bien ksh :-)
@@vraiverifiableinvisiblekta2887 Oe bon sa critique bash mais quand t'aura besoin de le transposer dans un autre OS type termux ou MacOs ton petit script ksh va t'afficher un beau petit message d'erreur ! Contrairement au bash qui est multiplateforme
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Pour moi il est important de mettre ces constantes en haut du fichier car c’est plus rapide pour les modifier et si quelqu’un d’autre utilise le script il n’a pas besoin de comprendre ce qui ce passe pour changer les paramètres :)
Complètement du même avis. Ces variables permettent de configurer le script. Il y a tout intérêt à ce que celles-ci soient visibles et facilement accessibles. On peut facilement se retrouver face à un script composé d'une centaine de lignes. Et là bonjour pour retrouver LA variable à modifier qui nous intéresse.
De plus, en positionnant ces variables en début de script, on annonce clairement les variables qui sont modifiables par un dev "client" du script. Au delà de ces variables, c'est "touche pas à ca".
Je fais pareil à une exception. En haut ce sont les variables générales du script. Dans les fonctions ne se trouvent que les variables qui ne seront utilisées que localement.
"on est là pour faire du Bash, on n'est pas ici pour faire de l'art plastique" 🤣👌
Boris Vian 2.0
Me suis senti attaqué j'adore les bannières dans les scripts
J'adore ton style ultra chill dans tes tutos ^^.
J'apprends plein de choses, j'approfondis mes connaissances et en plus je kiff la musique d'ambience ^^.
Perso ça ne me gêne pas du tout le retour à la ligne avant `then`.
Aussi, on peut utiliser le tiret normal au lieu du tiret bas pour le nom des fonctions (mais pas pour le nom des variables).
bonjour,
pour les fonction je conseille a mes stagiaires qu'elle porte un nom avec le même préfixe style : func_create_archive_filename pour ton exemple.
cela permet dans de gros script quand la fonction est appelée après plusieurs dizaine voir centaine de ligne de savoir quand on voit "func_create_archive_filename" que c'est bien un appel de fonction.
et pour les variable je leur dis toujours de les protéger avec des double quotes surtout dans les tests mono crochet. ( votre maman vous a toujours dis de vous protéger ).
merci pour cette vidéo.
J'ai un peu la même logique, mes fonctions commence toujours par f_quelquechose
J'ai découvert ta chaîne par mon frère récemment, c'est vraiment du lourd !
Ton format vidéo quand tu expliques avec le terminal me rappelle mes années "piscine" à l'école :p
14:25 Ou "backup_folderlist" sinon ;)
Est-ce que c’est toi qui taffes chez ledger ? 🙂
Propre, tu m'as donné envie de faire du bash plus en profondeur avec des scripts au lieu de taper 1 à 1 des commandes dans le terminal comme j'ai l'habitude de faire
Merci! Tu donnes vraiment de super conseils!
Excellent boulot!
Pour le coup je suis pas tout à fait d'accord quand tu déclare les constantes type folders_to_backup directement dans le main à la fin du fichier
Pour ce genre de variables, le laisser en haut permet de les utiliser comme un "fichier de configuration" et ça évite de devoir descendre dans le main pour parametrer le truc
"On est pas ici pour faire de l'art plastique"
Moi qui fait tout le temps des bannières super jolies pour rendre plus lisible le script : *D:*
Il ne faut pas oublier aussi de renommer toutes les variables dans les fonctions 😆
Maurice Léon yep, j’ai zappé :p
Trés intéressant , merci .
Ta logique est vraiment solide meme si elle chagrine certain (plutôt les feignasses de mon points de vu , c est de bonne augure ).
Un bon développeur est une "feignasse", sinon autant faire de l'assembleur directement :)
"Comme est là ici pour faire du bash, on n'est pas ici pour faire de l'art plastique" 😂😂👌
C'est un truc qui me rend ouf, mais rien de bien grave mais quand même.
Expliquer une syntaxe, c'est expliquer *comment* elle va être interprétée et *pourquoi* 😗
Mais qu'est ce qu'elle est bien cette chaine !!
super conseils, merci!
Très intéressant. Je partage la même vision du code: de petites fonctions qui font bien ce qu'elles annoncent, et seulement ce qu'elles annoncent. Bref du code auto-documenté (self-describe).
Bonjour; svp j'ai un code a verifier c esst ca vous ne derange pas, c'est un petit code mais j'ai un soucis. j attend ton retour
Salut,
Je ne suis pas totalement d'accord avec tout ceci.
Niveau commentaire, pour moi c'est indispensable, surtout dans des très gros scripts, savoir que tel fonction utilise tel variable, quel a besoin de tel paramètre, ou inversement en un seul coup d'œil, c'est top. Après un commentaire qui indique la même chose que le nom de la variable n'a effectivement pas d'intérêts.
Niveau art plastique ^^, je trouve que c'est pratique pour séparer le script en block, j'utilise personnellement beaucoup ceci pour des gros scripts encore une fois, avec une balise début et fin.
Pour les variables, globalement d'accord, sauf pour ces deux variables, qui sont susceptibles d'être changé. Dans ce cas, au début du script c'est le plus adapté, encore une fois si le script est conséquent. Avec même un petit commentaire pour dire de séparer par un espace les répertoires a sauvegarder.
Je rajouterai un autre truc indispensable, des tests, vérifier le bon format des variables, si tout c'est bien passé, afficher des vrais infos, parser les erreurs etc ....
Un script doit contenir le maximum d'information, que ce soit en commentaire, qu'en logs.
Cela n'enlève rien à la qualité de tes vidéos.
Salut Xa Taz !
Pour les commentaires je suis d'accord avec toi, ma critique était effectivement plus adressée aux commentaires redondants.
Pour l'art plastique c'est peut-être plus une question de préférence, j'aime avoir le minimum de sauts de lignes pour avoir plus de code dans un meme écran mais je peux comprendre que ton coté ASCII artiste te démange de temps en temps :p
J'ai peut être paru un peu extreme dans la video mais je te rejoins aussi pour les constantes qui sont plus pratique en début de fichier.
Je pense que j'aurais pu plus insiter sur le fait de penser à si il y a une raison de placer ses variables à un endroit.
Si plusieurs variables n'ont rien a voir les unes avec les autres et n'on pas vocation a être modifiées souvent, alors il est plus logique de les mettre proche de là ou elles sont utilisés pour facilité la comprehension.
Je te rejoins également pour les tests et les messages d'erreur.
Merci d'avoir partagé ton experience ;)
Bravo !
Hello, Merci je m'initie à bash à votre video m'a bien aidé , en 16:30 j'ai appris bien plus de choses qu'après avoir passé des heures sur d'autres sites à me prendre la tête; Ceci étant , timecode 4:36 vous dites"si je prends une variable qui n'existe pas, ça me dit qu'elle est non vide ? après vérif il apparaît qu'elle est vide... et vous poursuivez en disant que xyz a été interprété comme une chaine de caractère alors qu'en fait c'était une variable" !!!! Là je ne vous suis plus , c'est une variable ou pas , ce n'est pas une variable car pour ma part elle n'a jamais été initialisée dans votre exemple; Merci de votre retour
Sarah
Salut Sarah !
En bash il n’y a pas de types pour les variables contrairement au autres languages.
Donc toutes les variables sont des chaînes de caractères. ( même les nombres)
Merci pas sûr d'avoir tout pipé notamment à 5:15 [[ -n $adawd......]] ça ne décrit rien parce que cette variable existe ??? alors pourquoi est ce que ça ne décrit rien comme vous le dites ? c'est illogique par rapport à votre réponse qui précise que toutes les variables sont des chaines de caractères , alors si c'est le cas ça devrait afficher non vide n'est ce pas ? Merci
Sarah
Une chaîne de caractère même vide, reste de type chaîne de caractère ;)
Par exemple
$chaineDeCaractere = “”
Merci dude ! Sujet pertinent, comme d'hab :)
Vidéo très sympa. Le bash (shell) étant un langage très vieux, est-ce toujours un bon point d’entrée pour apprendre à coder? Je pense qu’on peut considérer ta manière de faire comme de la programmation fonctionnelle non?? Merci
Salut Soufian, je pense que c'est très mauvais point d'entré pour apprendre a coder car il y a plein de chose manquante et de "hack" qui donne de très mauvaise habitudes.
Mais oui on peu un peu considerer ca comme de la programmation fonctionnelle
@@cocadmin non, ce n'est pas encore de la programmation fonctionnelle, car il y à des états internes qui modifient le fonctionnement des fonctions appellées (l'état est ici stocké dans des variables, et changerait le fonctionnement d un même appel de fonction fait à des moments différents, selon l état de ces variables). En fonctionnel, un appel à une fonction se fait avec un jeu de paramètrs (des "arguments"), et appeler une fonction avec les mêmes arguments dois toujours donner le même résultat, quel que soit les opérations faites avant. Ici l appel dépendra de l'état interne du script et même de la fonction. Il faudrait virer toutes les définitions de variables et les remplacer par des arguments aux fonctions (je simplifie bcp trop, c'est un peu difficile à résumer en quelques lignes). En fait, en général en script shell il est difficile d être 100% en programmation fonctionnelle, car on va modifier l état de quelque-chose (et plein de variables (IFS, etc) peuvent même modifier le comportement même si le script lui-même ne les contient pas!). Mais on peut quand même s en approcher (comme ici, ou la factorisation du code effectuée le rapprochera de la programmation fonctionnelle).
@@cocadmin Par contre c'est une belle "factorisation" du code.
Le script final est devenu beaucoup plus lisible et facile à comprendre et modifier.
(Même si il est devenu malheureusement buggé car le renommage des variables n'à pas été fait partout!).
Bonjour Cocadmin ! Depuis quelques mois je me suis mis à faire mes scripts bash pour automatiser des tâches redondantes, je gagne un temps considérable. J'essaie continuellement d'améliorer mon code en faisant des recherches et avec tes vidéos ma compréhension de bash est beaucoup plus clair, merci pour ton partage. Cela dit, à 15:41 de ta vidéo, tu mets ta fonction "main" en commentaire et appelle la fonction "print_start_status_message" et j'avoue que je ne comprends pas bien l'utilité de la manoeuvre...?
Salut, pour ma part j'aurais ajouté des vérification de l'existence des chemins et des fichiers.
Suivant la machine source j'aurais plutot fait tar sur celle-ci, envoyé sur la destination par rsync (l'archive ou les fichiers) et vérifié l'état a l'arrivée.
Je suis peut être un peu parano du réseau et ses coupures ^^
Yes, c'est un peu plus spécifique mais la validation est importante pour faire du code solide :)
Merci .
Comment tu as défini cette jolie flèche bleu dans ton prompt ? Svp
tu peux soit installer powerline, soit utiliser une font qui contient ces characters spéciaux et modifier ta variable $PS1
Je pense que la raison pour laquelle on met les variables au dessus ,est d'avoir un aperçu rapide ou faire un changement plus rapide du code..surtout quand t'as +300 lignes. pas besoin de lire tout le code pour trouver les variables...chacun sa methode
Pour les constantes je suis d' accord. Pour les variables un peu moins. Mais effectivement en script bash on a souvent plus de constantes comme des chemins de fichiers etc
@@cocadmin oui je pensais aux constantes pas aux variables
J'aurais plutôt nommé la méthode "create_archive_filename" en get_archive_filename qui aurait renvoyé une valeur et utilisé cette valeur pour initialiser une variable déclarée dans le main. Une méthode qui crée une variable, je ne trouve pas ca très élégant :)
svp , c'est quoi une constante vs variable ; Merci
Une variable peut être modifiée après sa créations alors qu’une constante a une valeur assigné à sa création que l’on ne voudra jamais changer par la suite dans notre code.
(Comme par exemple le chemin d’un fichier)
Un piege dans lequel je tombe trop souvent : quand une variable (souvent en argument de script) est un chemin de fichier/dossier, et que ce chemin contient un espace. Si cette variable n'est pas protegee avec des guillemets quand elle est utilise dans une sous-commande, KABOOM. Le pire c'est que parfois le script semble parfaitement marcher, sauf qu'en fait la ou les sous-commandes ont juste fonctionnees avec plusieurs arguments ou lieu de juste un pour ce chemin de fichier... Ca donne souvent des surprise du style nom de fichiers/dossiers partiels qui ont ete cree :D
Aïe ouai .. Pour éviter ca tu peux rajouter un peu de validation au debut de ton script/fonction et déclencher une erreur si il n'y a pas le bon nombre d'argument.
11:46 pour le coût je ne pense pas qu'il était nécessaire ici de faire une fonction pour remplacer une seule ligne, par contre un commentaire pour expliquer l'utilisation des paramètres pour qu'on ne soit pas obligé d'aller lire le man aurait été pas mal
slt. moi j'ai un souci avec virtualbox sur manjaro. il ne me fait pas voir mon DD externe depuis l'explorateur virtualbox quand je veut créer / chercher ma VM .vdi sur le DD externe.
et aussi bien une clé usb.
une idée ??
Hmm la comme ça difficile à dire 🤔
@@cocadmin
ouhai.. j'ai essayer sur Mint et c'est la même. alors hic pour moi.
Je me souviens que dans VMware il y avais un paramètre pour que un appareil usb se branche directement dans la vm. Peut être que tu peux chercher « usb pass through virtualbox Linux »
Salut Cocadmin, J'adore tes vidéos. Super clean, bien faite et surtout très pro. Continue comme ça.
Salut, je découvre et j'enchaîne tes vidéos. Pas tout vu, tu en parles peut être ailleurs, je me demandais si tu remontais tes modifs pour partager. Sûr que les scripts ne sont pas parfais, mais ils sont fonctionnels et partagés. Le collaboratif via l'amélioration étant dans l'essence de l'open source, je me posai la question ;)
Signé : Un barbu
Salut cocadmin
On peut donc faire des fonctions à tire-larigot sans que ça pose problème ? En tout cas c’est fou tout ce que je vais pouvoir améliorer sur mes scripts bash grâce à quelques vidéos que je viens de regarder c’est top et je t’en remercie !
attention quand même, il y a plusieurs oublis et erreurs dans la vidéo :
- les variables ne sont initialisées que dans la fonction main, et donc main **doit** être appelée en fin de script, même si vous ne voulez tester qu'une seule sous-fonction.
Il faut donc laisser le main final mais plutôt commenter, dans la fonction main, les lignes qu'on ne veut pas exécuter cette fois là pour notre test.
Sachant que la aussi certaines lignes (l appel à la fonction de nommage du fichier, par ex) peuvent être indispensables pour tester les lignes suivantes.
- De plus il à renommé (de belle façon) certaines variables... mais ne l'à fait qu'à un seul endroit! Cela à introduit des bugs: aux autres endroits il n'appèle pas le $nouveau_nom mais $ancien_nom (qui est du coup non défini, et donc retournera une chaîne vide). Il faut renommer partout!
- et un petit avertissement avant de nommer ou renommer des choses : il faut faire attention aux parties de noms communes: si vous avez une variable nommée "foo", et une autre nommée "vlah_foo_blah" (ou même n'importe quoi dans le script contenant la sous-chaîne "foo") : si vous voulez ensuite juste renommer la variable "foo", vous ne pouvez pas simplement lancer un chercher/remplacer global de "foo" en "bar" car ça modifiera aussi tous les autres endroits contenant "foo", et pas seulement ceux correspondant exactement à la variable "foo". (pour ce dernier soucis, il faut donc choisir des noms bien distincts les uns des autres pour les variables, et donc eviter en général d'avoir une variable dont le nom est contenu entièrement dans un autre nom de variable (ou commentaire ou valeur).
Dans la vidéo il à plutôt bien renommé ses variables! (mais à malheureusement oublié de les renommer partout).
C'est une blague à 16:00 "moi je ne fais presque jamais de test" ?
Je suis débutant sur linux et a 9:25 tu dit que c'est pas des files mais des folders, j'ai cru comprendre que tout est fichier dans linux, c'est peut-être dans cette idée que la personne a décidé de mettre backup_files !!
on peux voir ca comme ca mais c'est un peu tordu :p
Merci.
Les fondamentaux pas souvent respectés. Par contre j'aurai mis
/bin/env bash au lieu de /bin/bash pour le shebang.
Pas plutôt /usr/bin/env ?
@@luclu7_ je sais pas je fais tout le temps un which env avant :D
Top comme vidéo. Seul truc que j'aurais à redire c'est la création de fonction pas forcément utile: en soit, le script s'exécute, les fonctions ne sont pas exportées ou dupliquées, du coup est-il vraiment intéressant de tout mettre dans des fonctions ?
Bonne question!
Ce n'est pas juste pour la clarté mais c'est effectivement pour pouvoir plus facilement les exporter dans un fichier different et c'est aussi une bonne pratique de programmation en general parce que ca permet de pouvoir tester ton code.
C'est très facile de faire des tests unitaires sur des petites fonctions indépendantes mais c'est presque impossible d'en faire sur un gros morceau de code qui fait plein de choses a la fois.
Je savais pas qu'on pouvais utiliser les ${variables} comme ça, c'est beaucoup mieux pour la concaténation !
Hello,
Quel est le plugin vim qui te permet de faire de la complétion ?
cyril schaal je crois que c’est par défaut, c’est de la complétions bête que cherche dans le document actuellement (ctrl + n )
Si tu pouvais juste baisser la musique de fond ; ça serait top ! ... ( Pourquoi ? Parce qu'elle est diffusée sur un mode Hypnotique ... )
Yep je fait plus attention maintenant ;)
Il y a un autre grand utilisateur de BASH, c'est Dexter... juste que c'est pas les mêmes... xD
On dirait le professeur Xavier qui avance dans son fauteuil avec toi assis, crâne rasé et le travelling en background. Noraj. C'est marrant. 😄
Buddy haha fais gaffe jvai te mind control :p
@@cocadmin Pas la peine, je suis déjà abonné. 😄
$dest n'existe pas ! => c'est $backup_destination !!!!!
$backup_files non plus => c'est $folders_to_backup !!!!
Quand on modifie les noms des variables, il faut penser à changer partout ;-)
y'a quand meme un non sens : tu mets les variables en bas mais tu ne les utilises qu'au dessus puisque tes fonctions n'ont aucun parametres, c'est un peu pete pour l'argument de mettre les variables la ou elle sont utilisées ;)
je ne suis pas développeur Bash mais ça m'étonne que l'on puisse mentionner des variables et les déclarer après. Mais sinon j'ai bien aimé la vidéo
Ouais, enfin, le script ne fonctionne pas à la fin vu que les variables $dest et $backup_files ne sont plus définies...
Yep :(
😂 .. j'attendais de le voir ce commentaire.
J'attendais aussi à ce qu'il montre une astuce ou bonne pratique sur les paramètres à passer en fonction..
Mais bon .. en même temps quand tu vois 2 fonctions qui font juste un écho.. 😅 tu comprend que c'est juste pour l'exemple 😉
J'ai réussi à placer mon com ! Yes !
Salut ! J'aime bien tes vidéos, je viens d'en enchaîner quelques unes.
Par contre, petite remarque concernant les fonctions. Je ne vois absolument pas l'intérêt de les utiliser si elles ne contiennent que des variables globales.
Dans l'exemple de cette vidéo, on ne peut pas tester la fonction qui fait le tar juste en remplaçant "main" par "backup_files" par exemple.
Du coup, quand c'est fait comme ça, tout l'intérêt des fonctions est perdu.
Je pense qu'une fonction ne devrait utiliser que des variables locales et prendre des arguments, et là, en effet, on peut tester une fonction et ça a un intérêt (en plus d'être utilisable dans n'importe quel autre script indépendamment du nom des variables du script qui l'appelle).
Perso, si les fonctions ne sont pas indépendantes du script et de ses variables, ben je trouve que les utiliser, ça complique les choses. Et un script écrit proprement avec des noms de variables clairs est mieux.
folders c'est plutot une notion qui vient de windows... En Unix on dit directory
5:20 Aie ! Le double crochet oui mais non portable ;)
Il aurait été mieux de préconiser *if [ -n "$adawddfwndflkjjklfwe" ] ; then [...]* 😉
"Si ton code a besoin de beaucoup de commentaire, ton code est nul" -Les pro de la méthode Agile
Guillaume Bélanger bash 101
Bonjour, je bloque sur un exo, tu pourrai m'aidé ? :)
Viens sur le discord, on pourra surement t'aider ;)
discord.gg/4h2xBFh
Avec Napoléon tout aurait dû être en français !
3:12 Ce ne sont absolument pas des guillemets simples 🤔
Guillemet simple « ' »
Guillemet interprété (backtick) « ` »
Exemple :
echo 'echo lol' // Affiche *echo lol*
echo `echo lol` // Affiche *lol* car `echo lol` est interprété: lol -> echo lol > lol
Sous cotée le ${contenu} !
hi mottai boss
8:54 faut arrêter les conneries. On est pas là pour faire des dessins non d’une pipe 😂😂😂
Musique trop forte sur cet épisode, dommage.
Sinon bon épisode, continue
Je ferais gaffe la prochaine fois. Merci !
9:25 Techniquement faux ! 😇
Sur Linux, la philosophie est : « Tout est fichier », ce qui donne naissance à /proc 🙂
L'important reste *la volonté*, tout dépend à qui tu souhaites parler.
Créer des fonctions sans utiliser les paramètres (de fonction) et se reposer sur les variables globales est quand même bof…
Aussi, on mets toujours les constantes en haut de fichier, pas pour faire beau mais pour, en cas de modification, les trouver très rapidement …
Un collègue Devops …
C'est des scripts grand public, les gens ont pas que ça à foutre que de chercher dans tout le code si y'a des variables à changer et ou est-ce qu'elles sont, c'est pour ça que la règle tacite est de mettre les variables qui doivent être changées au tout début.
Il y a peut etre débat sur l emplacement des variables , mais si les gens n ont pa que ca a foutre , ils ont qu a l écrire eux même , non ?
@@philtoa334 bah non, ils n'ont pas que ça à foutre non plus 🤡
@@Albirew ouais finalement c est toujours les branleurs et les taches qui se plaignent .
Mais en programmation on repères plutôt vite les incapables.
Je fais pas beaucoup de prog, je sais pas si mon avis est important. Mais si un de mes apprenti me montre un script ou les var et constante de "configuration" sont pas au début et que je dois me casser le cul a trouver ou elles sont ces var, il risque de recommencer. faut arrêter de vouloir péter plus haut que sont cul sous prétexte d'être SYSADMIN.
@@philtoa334 C'est quoi le rapport avec les incapables? Pourquoi réinventer la roue si un script éprouvé fait déjà bien le taf? Pour flatter son égo?
Je fais pas mal de Bash j'aimerais ton avis -> https ://github.com/Jukoo/Hspot
Tu fait partis de ceux qui font des unit tests en bash :) Felicitations !
De ce que j'ai remarqué a premiere vue c'est surtout des inconsistances de style dans la manière dont tu declares les fonctions (mot clef function et parentheses sont parfois utilisé, parfois non ) et dans ton indentation.
Je le garde au chaud pour critiquer plus tard ;)
Pas de shebang dans le script hspot, de l'art plastique à tout va dans le script hspot (des sauts de lignes en plus, d'autres manquants), un manque de consistance important, des tests qui dépendent uniquement de si le script est en mode strict, du shebang en /bin/bash sans env, des tests unitaires avec des sleep partout (incluant des décimales), une compatibilité avec différentes versions bash douteuse.
C'est la difficulté avec Bash, un langage "batard" qui fonctionne de 1000 façons ... Trouver la façons homogène n'est pas chose aisée. Tu sembles t'être lancé dans une sacrée aventure !
@@o_be_one merci beaucoup 😃 c'est vraiment constructif ... Bon si j'ai pas mis le shebang c'est pour faire un fichier de configuration comme ça on peut activé des modules depuis le beehive (je me suis un peut inspirer des fichers config sous linux ) bon je pensais que c'était une bonne chose a faire 😊
@@cocadmin je prends notes 😊 🗒️
C'est un résumé rapide, mais si ça peut t'aider ça me fait plaisir ^^. J'avais peur d'être trop négatif dans mon message ... Je ne fais pas tant l'effort de faire mes scripts rigoureusement propre non plus.
hspot te paraît juste un fichier de configuration mais il contient du script, et pour cette raison c'est important de respecter la norme si tu veux être sûr que ça roule correctement partout (pas tout le monde utilise bash par défaut, par exemple c'est presque certain que quelqu'un sous ZSH voit le script crasher si il ne tape pas "bash hspot" ; ce sera aussi un problème que tu risques de rencontrer en mettant ça en tâche cron par exemple ; et la je dirai d'utiliser "#! /usr/bin/env bash" plutot que juste "/bin/bash"). Aussi selon le lien de cocadmin dans un autre commentaire (google.github.io/styleguide/shell.xml), Google considère OK de faire un script sans extension si il s'agit du script principal qui démarre les autres. Après les autres, les "modules", devrait contenir une extension. Il existe une forme de "combat" entre .sh ou .bash ... Je fais parti de l'école .bash, mais c'est une question de préférence au final. Je vois aussi de l'inconsistance dans hspot avec les [ ] et [[ ]]. Personnellement comme cocadmin je recommanderai les [[ ]] comme le choix par défaut, ça t'évitera bien des problèmes et le fait de ne pas mixer les 2 te facilitera la lecture.
Y a beaucoup de raccourcis, tu sembles avoir soit une bonne expérience soit des connaissances plutôt large dans le scripting bash (pour être franc on dirait même que c'est des morceaux de scripts assemblés ci et là tellement y a de différences).
Passe sur le Discord si tu n'y es pas déjà et fait signe si fais des mises à jour et souhaite avoir d'autres avis ^^ !
Hey voici mon script : gist.github.com/bernard-ng/c042072206604846bafe35bd35be9b63 ton avis ?
Merci bernard, je le met de côté pour la prochaine vidéo ;)
le bash c'est le mal....
le conseil numero un aurai pu etre: Eviter d'utiliser bash pour autre chose que des petits script simple :p
@@cocadmin voire plutot éviter carrément d'utiliser bash :-)
il existe fort heureusement une multitude de shells suivant l'esprit Bourne ou l'esprit Joy pour ma part j'aime bien ksh :-)
@@vraiverifiableinvisiblekta2887 Oe bon sa critique bash mais quand t'aura besoin de le transposer dans un autre OS type termux ou MacOs ton petit script ksh va t'afficher un beau petit message d'erreur ! Contrairement au bash qui est multiplateforme