Pour le peu que j'en ai vu, Fish-le-shell c'est presque un shell Unix traditionnel.
Est-ce que les quelques manques de Bash par rapport à MSH que tu évoque seront pris en compte dans une future version ou est-ce que Fish te semble plus prometteur ?
Avant toutes choses, je tient à dire que je suis un gros newbie du shell, que je parle en toute subjectivité et je sait que les gens qui conçoivent ces logiciels ont probablement pensé à des choses que je ne peut même pas imaginer.
Pour fish j'ai pas vraiment d'avis, il m'a pas l'air très utile: c'est juste une nouvelle syntaxe à peine préférable. Mais comme l'interêt du scripting bash par rapport à des langages comme python est justement que l'interpréteur est répendu, Fish me parrait pas très utile. Autant promouvoir de "vrais" langages.
Pour ce qui est d'amelliorer bash, j'essaierais peut être de faire un truc ces vacances : l'idée est qu'on peut arriver en bash au même genres de filtres qu'avec MSH, si on considère que la quasi-totalité des informations manipulées par les programes du shell sont des nom de fichiers ou du texte formaté en colonne.
L'idée serait de faire un genre de grep, qui pourrais appeler des programmes externes pour trouver les propriétés de ses arguments, et aussi parser les formats de sortie "standards" (objets séparés par des retours à la ligne, propriétés séparées par des tabulation - les trois quarts des utilitaires marchent comme ça).
Avec ça, on ferais par exemple "ps aux | filter -c -t CPU -gt 10" ( -c pour définir un critère, -t pour désigner la colonne qui a la valeur CPU à sa première ligne, les autres tests utiliseraient le format standard (man test)).
On encore "ls -R | filter -c -e du -gt 1000" pour trouver les programe de plus d'un kilo-octet grâce à un appel de "du" (find le fait, mais c'est pour illustrer).
Avec un outil comme ça, je pense on disposerais en pratique des mêmes fonctionalités, dans tout les shells et sans la lourdeur des concepts de MSH.
Et si il est en C, il pourras devenir un des outils standards, ou même titre que skill et ses copains.
(si j'y arrive je ferais aussi un programme pour standardiser la sortie des programes Unix plus abscons, voir j'essaierais de contacter leurs auteurs pour leur proposer un switch supplèmentaire)
(PS: Attention, c'est pas une promesse, vu que j'ai tendance à ne jamais finir ce que je commence. et qu'en plus je bosse jusqu'en juin. Si quelqu'un veut faire ça à ma place, ça me gêne pas -_^ (ça serait sympa de m'en parler))
[^] # Re: un autre
Posté par un_brice (site web personnel) . En réponse au journal MSH beta est disponible mais ne sert à rien. Évalué à 2.
Avant toutes choses, je tient à dire que je suis un gros newbie du shell, que je parle en toute subjectivité et je sait que les gens qui conçoivent ces logiciels ont probablement pensé à des choses que je ne peut même pas imaginer.
Pour fish j'ai pas vraiment d'avis, il m'a pas l'air très utile: c'est juste une nouvelle syntaxe à peine préférable. Mais comme l'interêt du scripting bash par rapport à des langages comme python est justement que l'interpréteur est répendu, Fish me parrait pas très utile. Autant promouvoir de "vrais" langages.
Pour ce qui est d'amelliorer bash, j'essaierais peut être de faire un truc ces vacances : l'idée est qu'on peut arriver en bash au même genres de filtres qu'avec MSH, si on considère que la quasi-totalité des informations manipulées par les programes du shell sont des nom de fichiers ou du texte formaté en colonne.
L'idée serait de faire un genre de grep, qui pourrais appeler des programmes externes pour trouver les propriétés de ses arguments, et aussi parser les formats de sortie "standards" (objets séparés par des retours à la ligne, propriétés séparées par des tabulation - les trois quarts des utilitaires marchent comme ça).
Avec ça, on ferais par exemple "ps aux | filter -c -t CPU -gt 10" ( -c pour définir un critère, -t pour désigner la colonne qui a la valeur CPU à sa première ligne, les autres tests utiliseraient le format standard (man test)).
On encore "ls -R | filter -c -e du -gt 1000" pour trouver les programe de plus d'un kilo-octet grâce à un appel de "du" (find le fait, mais c'est pour illustrer).
Avec un outil comme ça, je pense on disposerais en pratique des mêmes fonctionalités, dans tout les shells et sans la lourdeur des concepts de MSH.
Et si il est en C, il pourras devenir un des outils standards, ou même titre que skill et ses copains.
(si j'y arrive je ferais aussi un programme pour standardiser la sortie des programes Unix plus abscons, voir j'essaierais de contacter leurs auteurs pour leur proposer un switch supplèmentaire)
(PS: Attention, c'est pas une promesse, vu que j'ai tendance à ne jamais finir ce que je commence. et qu'en plus je bosse jusqu'en juin. Si quelqu'un veut faire ça à ma place, ça me gêne pas -_^ (ça serait sympa de m'en parler))