Le souci n'est pas le shell pour des scripts rapides. Je fait aussi beaucoup de shell, parce que c'est rapide de torcher un truc de façon incrémental.
Le souci, c'est dire que le shell est génial pour monter un gros truc alors que :
c'est lent ( faut assez souvent faire des forks, ce qui a un cout certes sans doute invisible sur nos machines surpuissante, sans doute plus quand tu veux démarrer vite une VM ou un containeur ), l'interpréteur bash est pas vraiment optimisé pour ça, même si il semble que dash s'en sorte mieux.
les primitives de traitement sont quand même loin de l'idéal sur autre chose que des lignes. IE, on oublie des structures de haut niveau ( alors que pour openrc, on voit qu'il y a clairement un semblant d'orientation objet avec le fait d'avoir une fonction start, une stop, etc, mais que le shell ne le permet pas ). C'est sur que pour de l'analyse de texte et des ones liners, ça passe. Pour enchainer des commandes que tu aurais taper à la main, ouais. Au dela, mhh bof.
qu'il y a une syntaxe un peu baroque ( test vs [ , < vs -lt, etc ) et surtout le besoin de compenser avec des commandes qui sont pas unifiés.
qu'il y a pas les features "modernes" comme un espace de nommage, ou les threads. Même les primitives unix sont pas la. Tu as vaguement les signaux, mais les sémaphores, tu oublies, Creation de fichier temporaire, y a toujours un maigre risque de race condition ( entre le moment ou le fichier est ouvert et le moment ou il est crée, même si en pratique, j'ai du mal à voir un cas ou ça importe ), etc. Les APIs posix, tu as en général pas accès ( et parfois, c'est distro dépendant, genre les sockets qui sont pas activés sur Debian ).
qu'il y a fort peu de libs de test, et que ça rentre pas dans les habitudes des gens qui font du bash ( je sais que c'est faisable, c'est juste que ça rentre pas dans les pratiques usuels )
l'outillage est assez pauvre. La ou des langages comme perl ou python offre divers débuggeurs, profileurs, analyseurs, bash offre un débuggeur qui est dans un état de maintenance, en dehors du projet principal et globalement, c'est tout ce qui existe d'à peu prés avancer ( ça, et set -x, et globalement, la plupart des langages de script le propose aussi, comme rappelé sur http://rigaux.org/language-study/scripting-language/ ).
Encore une fois, tu peux faire un truc qui marche sur un coin de table pendant 5 minutes, je le fait assez souvent. Tu peux même en faire plein. Et je suis sur que tu peux faire tout un tas de trucs.
Mais si tu veux faire un truc qui va tenir plus longtemps et plus gros, je pense ( tu as le droit de pas être d'accord ) que c'est mieux de faire autre chose que du shell ( ça veut pas dire que tu va pas faire de la merde en perl, en python, en C ou autre non plus ). Le système d'init d'une distribution est le seul exemple qui me vient en tête de gigantesque code linbre en shell ( le build system de Mandrake étant le deuxième, et les gros bouts d'openshift étant le 3eme ).
Ensuite, tu as le droit d'en faire, personne t'interdit si ça te va. J'ai aussi un collègue qui en fait tout le temps, il m'écoute pas, et il le vit très bien.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 10.
Le souci n'est pas le shell pour des scripts rapides. Je fait aussi beaucoup de shell, parce que c'est rapide de torcher un truc de façon incrémental.
Le souci, c'est dire que le shell est génial pour monter un gros truc alors que :
c'est lent ( faut assez souvent faire des forks, ce qui a un cout certes sans doute invisible sur nos machines surpuissante, sans doute plus quand tu veux démarrer vite une VM ou un containeur ), l'interpréteur bash est pas vraiment optimisé pour ça, même si il semble que dash s'en sorte mieux.
les primitives de traitement sont quand même loin de l'idéal sur autre chose que des lignes. IE, on oublie des structures de haut niveau ( alors que pour openrc, on voit qu'il y a clairement un semblant d'orientation objet avec le fait d'avoir une fonction start, une stop, etc, mais que le shell ne le permet pas ). C'est sur que pour de l'analyse de texte et des ones liners, ça passe. Pour enchainer des commandes que tu aurais taper à la main, ouais. Au dela, mhh bof.
qu'il y a une syntaxe un peu baroque ( test vs [ , < vs -lt, etc ) et surtout le besoin de compenser avec des commandes qui sont pas unifiés.
qu'il y a pas les features "modernes" comme un espace de nommage, ou les threads. Même les primitives unix sont pas la. Tu as vaguement les signaux, mais les sémaphores, tu oublies, Creation de fichier temporaire, y a toujours un maigre risque de race condition ( entre le moment ou le fichier est ouvert et le moment ou il est crée, même si en pratique, j'ai du mal à voir un cas ou ça importe ), etc. Les APIs posix, tu as en général pas accès ( et parfois, c'est distro dépendant, genre les sockets qui sont pas activés sur Debian ).
qu'il y a fort peu de libs de test, et que ça rentre pas dans les habitudes des gens qui font du bash ( je sais que c'est faisable, c'est juste que ça rentre pas dans les pratiques usuels )
l'outillage est assez pauvre. La ou des langages comme perl ou python offre divers débuggeurs, profileurs, analyseurs, bash offre un débuggeur qui est dans un état de maintenance, en dehors du projet principal et globalement, c'est tout ce qui existe d'à peu prés avancer ( ça, et set -x, et globalement, la plupart des langages de script le propose aussi, comme rappelé sur http://rigaux.org/language-study/scripting-language/ ).
Encore une fois, tu peux faire un truc qui marche sur un coin de table pendant 5 minutes, je le fait assez souvent. Tu peux même en faire plein. Et je suis sur que tu peux faire tout un tas de trucs.
Mais si tu veux faire un truc qui va tenir plus longtemps et plus gros, je pense ( tu as le droit de pas être d'accord ) que c'est mieux de faire autre chose que du shell ( ça veut pas dire que tu va pas faire de la merde en perl, en python, en C ou autre non plus ). Le système d'init d'une distribution est le seul exemple qui me vient en tête de gigantesque code linbre en shell ( le build system de Mandrake étant le deuxième, et les gros bouts d'openshift étant le 3eme ).
Ensuite, tu as le droit d'en faire, personne t'interdit si ça te va. J'ai aussi un collègue qui en fait tout le temps, il m'écoute pas, et il le vit très bien.