Envoyer vos script bash pour être critiqués dans la prochaine vidéo :) thomas @cocadmin.com Newsletter: cours.cocadmin... Rejoignez le discord: / discord
afin d'évité un double if tu pouvais utilisé les option de grep qui sont : "q" : n'affiche rien si il trouve la ligne et sort a 0 ( $?) "s" : si le fichier est pas la grep dit rien et sort a 1 ce qui donne : if ! grep -qs "$config_line" "$wsl_config_file" ; then echo "$config_line" >> "$wsl_config_file
assumer verbe transitif 1. Prendre à son compte ; se charger de. Assumer une responsabilité. 2. Accepter consciemment (une situation, un état psychique). Assumer une situation difficile (assomption).
La base pour la fiabilité d'un script bash, c'est `set -eu`. C'est le mode strict : aucune erreur non gérée n'est tolérée, aucune variable indéfini n'est tolérée. Sans ça, c'est vite difficile à débugger.
Comme on dit, explicite c'est mieux qu'implicite. Je recommande: * Les options longues pour les commandes utilisées dans les scripts. Par exemple --insecure est plus parlant que -k * Créer des options avec getopt/getopts plutôt que d'utiliser des paramètres. Il est plus facile de faire évoluer les scripts comme ça * Le mot clé "function" pour déclarer les fonctions * Utiliser des variables locales dans les fonctions * Éviter les one liners, "if [] then fi" est plus claire que "[] &&" * Éviter "echo" ou "printf" les variables pour les rediriger à un pipe "|", c'est mieux d'utiliser "here doc" et "here string" à la place. echo ' ' n'est pas pareil à cat
J'utilise les here docs seulement quand je veux rediriger une chaine avec plusieurs lignes perso, je vois pas l'intérêt de remplacer un petit echo avec ça.
Bonne vidéo, mais je vais être obligé de chipoter sur ton dernier script: * Si le fichier n'existe pas: pas de message d'erreur, rien... * Si tu as la ligne "root = /etc" dans le fichier, le script ne fais rien. Utilise plutôt grep -x * Si tu as des caractères regex (un . pas example) dans ta ligne à rajouter, ça peut foutre la grouille. Utilise grep -F * Ton grep devrait utiliser -q pour pas avoir des sorties qui ne t'intéresse pas (et ça améliore aussi les perfs) * Tu ne met pas de quotes autour de la variable dans ton premier if * Pas de code de retour explicite * Tu ne teste pas si ton echo réussi. Du coup si tu rajoutes des commandes après, il va les jouer même en cas d'erreur Petit oneliner: grep -qFx "$config_line" "$wsl_config_file" || echo "$config_line" >> "$wsl_config_file"
slt Attention a $?, cela renvoie le code retour de la derniere commande donc a 3:50, c'est le code retour de ls. J'avais entendu idempotence quand j'avais commence sur Ansible Mais appliquer ce principe au bash est une bonne habitude Sinon bravo pour ta video tu seras au DevOps Days Montréal ?
Yep, je l'ai remarqué aussi au montage mais jme suis dit que ca passerais inaperçu :p Je n'ai jamais été aux devops days mais pourquoi pas, est-ce que tu y es deja allé ?
@@cocadmin non jamais fait de devops, mais un ancien collègue avait participe a la devops de Paris, il en était revenu avec des étoiles dans les yeux. Je suis en train de voir si ma boite veut bien nous envoyer a devopsdays.org/events/2019-montreal/welcome/ car c'est 175 dollars...
Très bonnes vidéos. Pour éviter le double "if" j'aurais codé comme ça en gardant le contrôle de l'existence du fichier: conf_file="/home/tinux/mon_fichier_de_conf" conf_line="root = /" if [ -f "${conf_file}" ] ; then grep -q "${conf_line}" "${conf_file}" || echo "${conf_line}" >> "${conf_file}" fi
super vidéo merci, très instructif seul point négatif : on assume de faire des fautes de français, on suppose savoir CE qu'il se passe dans la machine.
9:42 Je mitigerai l'utilisation de l'option `-f`, elle est certes pratique mais EXTRÊMEMENT fatale 😱😱😱 Un `rm -f / app` et tu es dans le joie ultime quand tu t'en rends compte 🤣🤣🤣
Hi ! cocadmin merci pour tes conseils, juste une petite question : confonds-tu le mot assumer avec présumer ou est-ce un terme approprié dans le context BASH ?
J'ai du mal à associer la notion de solidité avec Bash honnêtement : si un programme que t'utilises dans tes scripts s'est fait update (par exemple, une fonction qu'il avait a été supprimée ou remplacée par une autre), d'un seul coup tu peux avoir des dizaines de scripts à revoir selon le nombre de scripts qui dépendent du programme, et ça me donne l'impression de bosser avec une version cauchemardesque des modules d'autres langages. C'est ce qui fait que Bash m'a toujours repoussé. Si je veux coder un script, j'utilise Python 3.
Cool ! Je connaissais pas cette notion d' idempotence, que je trouve très intéressante. En plus, comme tu le dis dans la vidéo, tu as fais attention à bien suivre tes propres conseils concernant la façon de coder en bash. Quoique (?!)... J' ai pas vérifié, mais tu conseillais pas plutot d'utiliser la notation "${variable}" au lieu de "$variable" ? ;-)
Ça aurait été bien de parler de: - comment vérifier si le script est exécuté en root (variable "$EUID" ) - l'utilisation de trap pour exécuter une commande de nettoyage après un SIGQUIT (Ctrl+C) - commande install au lieu de cp qui permet de definir le propriétaire et les droits lors de la copie - apt-get au lieu de apt, apt n'étant pas prévu pour s'exécuter dans un script (ce qui génère un petit message d'avertissement de sa part) - contrôler la verbosité des commandes voir tout mettre en silencieux et en faire une soit-même
J'adore tes vidéos, Thomas. Juste : "assumer", pour le newby (néophyte), je suis pas sûr que ce soit très clair. Pas facile de trouver un équivalant en français. On pourrait dire "présumer" comme le dit un commentaire, mais c'est pas suffisant non plus. "Présumer l'existence de…" serait peut-être le mieux. C'est juste mon $cent. Surtout l'occasion de saluer ton travail une nouvelle fois. Merci à toi.
Salut Cocadmin, je suis étudiant dans une branche système et réseau et j'ai du mal à m'y retrouver dans les différents environnements tu pourrais faire une vidéo explicative ?🤗😂
13:50 Utilisez un sed + un commentaire pour éviter de réinsérer une ligne dans un fichier que plutôt d'avoir un merdier de condition PAr exemple: sed -i '/#TA_LIGNE/d' /etc/config echo "blablablabla #TA_LIGNE">> /etc/config
Yo frérot je me redirige vers le monde obscure du dev ops, j'aime bien ta pedagogie mais je voulais prendre quelque formations et je voulais savoir si t'es éligible au cpf ?
Mr svp j'ai besoin de votre aide pour cet exercice : écrit un script qui permet de saisir le nom d'un étudiant (on considère que les noms sont distinct) . créé un fichier portant le nom de ce étudiant.ce fichier contiendra la liste des matières ainsi les moyennes de chaque étudiant.votre script doit donc permettre d'enregistrer chaque et sa moyenne selon le format suivant : matière : moyenne.on précise que les moyennes sont distinct.votre script dont aussi permettre de calculer la moyenne Algébrique de chaque étudiant
Personnellement, je trouve mkdir -p est un peu risqué dans le sens où on va écraser le contenu de premier répertoire créé. Si on exécute la commande par erreur par exemple. Alors avec mkdir tout cours y aurait un message pour me prévenir
yes mais souvent pour des petite scripts bash est plus pratique. Pour des plus gros projets, bash devient difficile a lire et a maintenir, et la python vient a la rescousse :)
afin d'évité un double if tu pouvais utilisé les option de grep qui sont :
"q" : n'affiche rien si il trouve la ligne et sort a 0 ( $?)
"s" : si le fichier est pas la grep dit rien et sort a 1
ce qui donne :
if ! grep -qs "$config_line" "$wsl_config_file" ; then
echo "$config_line" >> "$wsl_config_file
Je ne connaissait pas -s
Le double if est pas terrible effectivement.
@@cocadmin ma magie du bash justement :D
Sans "if", en une ligne : stat /etc/wsl.conf && grep "root = /" /etc/wsl.conf || echo "root = /" >> /etc/wsl.conf
pourquoi se passer de if qui est un buildin de bash et sh sachant que cela rend la chose plus lisible ?
@@FabienTEBALDINI
et un if en une ligne ressemble a cela :
if ! grep -qs 'root = /' /etc/wsl.conf ; then echo "root = /" >> /etc/wsl.conf ; fi
Envoyer vos script bash pour être critiqués dans la prochaine vidéo :)
thomas @cocadmin.com
C'est vraiment top. C'est super bien expliqué, simple, clair, ludique 👍
assumer
verbe transitif
1.
Prendre à son compte ; se charger de.
Assumer une responsabilité.
2.
Accepter consciemment (une situation, un état psychique).
Assumer une situation difficile (assomption).
La base pour la fiabilité d'un script bash, c'est `set -eu`. C'est le mode strict : aucune erreur non gérée n'est tolérée, aucune variable indéfini n'est tolérée. Sans ça, c'est vite difficile à débugger.
I like it ! Explications claires et précises comme de l'eau de roche c'est plaisant à écouter et à reproduire 👊🏿
Comme on dit, explicite c'est mieux qu'implicite. Je recommande:
* Les options longues pour les commandes utilisées dans les scripts. Par exemple --insecure est plus parlant que -k
* Créer des options avec getopt/getopts plutôt que d'utiliser des paramètres. Il est plus facile de faire évoluer les scripts comme ça
* Le mot clé "function" pour déclarer les fonctions
* Utiliser des variables locales dans les fonctions
* Éviter les one liners, "if [] then fi" est plus claire que "[] &&"
* Éviter "echo" ou "printf" les variables pour les rediriger à un pipe "|", c'est mieux d'utiliser "here doc" et "here string" à la place.
echo '
' n'est pas pareil à cat
J'utilise les here docs seulement quand je veux rediriger une chaine avec plusieurs lignes perso, je vois pas l'intérêt de remplacer un petit echo avec ça.
@@auronkardek Here stings est la version "courte" de here docs. Par exemple, command
Bonne vidéo, mais je vais être obligé de chipoter sur ton dernier script:
* Si le fichier n'existe pas: pas de message d'erreur, rien...
* Si tu as la ligne "root = /etc" dans le fichier, le script ne fais rien. Utilise plutôt grep -x
* Si tu as des caractères regex (un . pas example) dans ta ligne à rajouter, ça peut foutre la grouille. Utilise grep -F
* Ton grep devrait utiliser -q pour pas avoir des sorties qui ne t'intéresse pas (et ça améliore aussi les perfs)
* Tu ne met pas de quotes autour de la variable dans ton premier if
* Pas de code de retour explicite
* Tu ne teste pas si ton echo réussi. Du coup si tu rajoutes des commandes après, il va les jouer même en cas d'erreur
Petit oneliner: grep -qFx "$config_line" "$wsl_config_file" || echo "$config_line" >> "$wsl_config_file"
slt
Attention a $?, cela renvoie le code retour de la derniere commande donc a 3:50, c'est le code retour de ls.
J'avais entendu idempotence quand j'avais commence sur Ansible
Mais appliquer ce principe au bash est une bonne habitude
Sinon bravo pour ta video
tu seras au DevOps Days Montréal ?
Yep, je l'ai remarqué aussi au montage mais jme suis dit que ca passerais inaperçu :p
Je n'ai jamais été aux devops days mais pourquoi pas, est-ce que tu y es deja allé ?
@@cocadmin non jamais fait de devops, mais un ancien collègue avait participe a la devops de Paris, il en était revenu avec des étoiles dans les yeux. Je suis en train de voir si ma boite veut bien nous envoyer a devopsdays.org/events/2019-montreal/welcome/ car c'est 175 dollars...
Quand ils annoncerons les themes des speech jvai ptet demander a ma boite aussi ca peux être interessant :)
Vraiment lourd ces petits détails qui font la diff🤩😉
3:50 Aïe ! Tu es ici en train de tester le code de retour de la commande `ls` :D
Très bonnes vidéos.
Pour éviter le double "if" j'aurais codé comme ça en gardant le contrôle de l'existence du fichier:
conf_file="/home/tinux/mon_fichier_de_conf"
conf_line="root = /"
if [ -f "${conf_file}" ] ; then
grep -q "${conf_line}" "${conf_file}" || echo "${conf_line}" >> "${conf_file}"
fi
super vidéo merci,
très instructif
seul point négatif : on assume de faire des fautes de français, on suppose savoir CE qu'il se passe dans la machine.
9:42 Je mitigerai l'utilisation de l'option `-f`, elle est certes pratique mais EXTRÊMEMENT fatale 😱😱😱
Un `rm -f / app` et tu es dans le joie ultime quand tu t'en rends compte 🤣🤣🤣
Je pense que la commande rm -rf / ne fait plus rien sans l'option --no-preserve-root et l'exécuter sans sudo risque pas de faire beaucoup de dégâts
Hi ! cocadmin
merci pour tes conseils, juste une petite question : confonds-tu le mot assumer avec présumer ou est-ce un terme approprié dans le context BASH ?
Oui je mélange avec assuming en anglais. J’essayerais de faire gaffe la prochaine fois ;)
@@cocadmin ca arrive a tout le monde, les faux amis, je croix supposer c est le terme le plus approprié.
Merci pour la video
J'ai du mal à associer la notion de solidité avec Bash honnêtement : si un programme que t'utilises dans tes scripts s'est fait update (par exemple, une fonction qu'il avait a été supprimée ou remplacée par une autre), d'un seul coup tu peux avoir des dizaines de scripts à revoir selon le nombre de scripts qui dépendent du programme, et ça me donne l'impression de bosser avec une version cauchemardesque des modules d'autres langages. C'est ce qui fait que Bash m'a toujours repoussé. Si je veux coder un script, j'utilise Python 3.
Pour un petit script bash sera plus rapide et plus simple mais pour un plus gros script je suis d'accord avec toi.
C'est difficile a rendre solide.
Vraiment tres instructif!
Tu a fait comment pour le l'invite de commande?
Cool ! Je connaissais pas cette notion d' idempotence, que je trouve très intéressante.
En plus, comme tu le dis dans la vidéo, tu as fais attention à bien suivre tes propres conseils concernant la façon de coder en bash. Quoique (?!)... J' ai pas vérifié, mais tu conseillais pas plutot d'utiliser la notation "${variable}" au lieu de "$variable" ? ;-)
Chhhhut ! 🤫
super
Ça aurait été bien de parler de:
- comment vérifier si le script est exécuté en root (variable "$EUID" )
- l'utilisation de trap pour exécuter une commande de nettoyage après un SIGQUIT (Ctrl+C)
- commande install au lieu de cp qui permet de definir le propriétaire et les droits lors de la copie
- apt-get au lieu de apt, apt n'étant pas prévu pour s'exécuter dans un script (ce qui génère un petit message d'avertissement de sa part)
- contrôler la verbosité des commandes voir tout mettre en silencieux et en faire une soit-même
J'adore tes vidéos, Thomas.
Juste : "assumer", pour le newby (néophyte), je suis pas sûr que ce soit très clair. Pas facile de trouver un équivalant en français. On pourrait dire "présumer" comme le dit un commentaire, mais c'est pas suffisant non plus. "Présumer l'existence de…" serait peut-être le mieux.
C'est juste mon $cent. Surtout l'occasion de saluer ton travail une nouvelle fois.
Merci à toi.
C'est super bien expliqué !
Salut Cocadmin, je suis étudiant dans une branche système et réseau et j'ai du mal à m'y retrouver dans les différents environnements tu pourrais faire une vidéo explicative ?🤗😂
13:50 Utilisez un sed + un commentaire pour éviter de réinsérer une ligne dans un fichier que plutôt d'avoir un merdier de condition
PAr exemple:
sed -i '/#TA_LIGNE/d' /etc/config
echo "blablablabla #TA_LIGNE">> /etc/config
Yo frérot je me redirige vers le monde obscure du dev ops, j'aime bien ta pedagogie mais je voulais prendre quelque formations et je voulais savoir si t'es éligible au cpf ?
malheureusement non pas pour l'instant.
@@cocadmin merci d'avoir répondu
Je peux en savoir plus sur l'histoire du root = / ?
C'est pour un pote.
Mr svp j'ai besoin de votre aide pour cet exercice : écrit un script qui permet de saisir le nom d'un étudiant (on considère que les noms sont distinct) . créé un fichier portant le nom de ce étudiant.ce fichier contiendra la liste des matières ainsi les moyennes de chaque étudiant.votre script doit donc permettre d'enregistrer chaque et sa moyenne selon le format suivant : matière : moyenne.on précise que les moyennes sont distinct.votre script dont aussi permettre de calculer la moyenne Algébrique de chaque étudiant
11:51 j'ai explosé de rire
j'aime trop votre arrière plan peut nous montre comment ta fait svp
j'explique ici ruclips.net/video/U5laGytJQeE/видео.html&
Personnellement, je trouve mkdir -p est un peu risqué dans le sens où on va écraser le contenu de premier répertoire créé. Si on exécute la commande par erreur par exemple. Alors avec mkdir tout cours y aurait un message pour me prévenir
C’est sûr que ça dépend toujours de ce que tu veux faire. Je pense qu’en général c’est mieux d’être sûr que les dossiers vont être la.
3:46 c'est le code d'erreur de 'ls' et non de mkdir '0'
Merci !
Hello, merci pour ta vidéo, tu utilises $variable et non ${variable}. C'est un oubli ? ;-)
Oui :)
@@cocadmin en tout cas bravo et merci pour tes vidéos. Dommage que tu sois si loin, je pourrais pas te payer un verre.
wahooooo comment faire pour un terminal animé comme le tient . "STP"
ruclips.net/video/U5laGytJQeE/видео.html
Estce qu'on peut utilisE python au lieu de Bash pour les scripts?
yes mais souvent pour des petite scripts bash est plus pratique. Pour des plus gros projets, bash devient difficile a lire et a maintenir, et la python vient a la rescousse :)
Merci pour ta question, je me posais la même !
J'ai un code erreur qui a clignoté toute la vidéo ! Le code "assumer" 😂 c'est soit "je présume" ou alors "i assume"
Et les fonctions ? elles sont où les fonctions ? ? ? :) en tous cas merci pour ce tuto bash ;)
Haha c'est vrai ca manque de fonctions :p
@@cocadmin sans oublier le source de toutes les variables ;) . En tous cas bon boulot. Ta chaîne déchire. ;)
Merci! content que ca te plaise ;)