Je ne comprends pas votre vidéo. Ce n’est pas sérieux ?!

Non le langage bash est un vrai langage de programmation qui réponds à tous les critères reconnus pour le qualifier comme tel, ce n’est pas un simple fichier “batch” qui contient une liste de commandes. Par contre, comme son avantage est justement de pouvoir appeler facilement n’importe quelle commande, on va souvent utiliser ce raccourcis soit par simplicité soit pour utiliser l’outil le plus approprié plutôt que de l’écrire en bash natif. Mais on peut parfaitement faire un sed, un cat ou un scanner de port en bash sans utiliser de programme externe. — commentaire de Christophe Casalegno (Brain 0verride), cité en référence dans la vidéo.

Comment peut-on croire (se fonder sur) ce genre d’allégation ? C’est exactement l’inverse (source : Unix Stack Exchange, c.f. une réponse de Stéphane Chazelas) que vous dirons les spécialistes du Shell Unix.

Shells are a higher level language. One may say it’s not even a language. They’re before all command line interpreters. The job is done by those commands you run and the shell is only meant to orchestrate them.

In 50 years, we’ve not found better than that API to harness the power of commands and have them cooperate to a task. That’s probably the main reason why people are still using shells today.

And shells have not been designed to run like that, they have no pretension to being performant programming languages. They are not, they’re just command line interpreters. So, little optimisation has been done on this front.

[Why is using a shell loop to process text considered bad practice?…] […] If we want to address some of those issues above, that becomes:

while IFS= read -r line <&3; do
  {
   printf '%s\n' "$line" | cut -c3 || exit
  } 3<&-
done 3< file
if [ -n "$line" ]; then
    printf '%s' "$line" | cut -c3 || exit
fi

That’s becoming less and less legible.