Il faut voir qu'un shell, n'est pas un simple lanceur de commande, il y a un gros travail de fait sur la completion, sur la gestion des jobs, sur les pipes, les redirections. Est-ce que tu implementes la gestions les jobs?
Ensuite, on l'utilise pour des raisons historiques, bash est présent sur tous les systèmes, du moins on trouve forcement un interpreteur sh.
Ce qui facilite la vie des admins, c'est en partie pour ca que les autotools n'utilisent que des outils unix standard: la portabilité au détriment de la vitesse.
De plus il existe différent shell plus ou moins rapide avec des syntaxes plus ou moins différentes. De ce que tu decris tu as envi d'un équivalent du language c, utilise alors tcsh, csh, ou (celui que je prefere parmis tous) zsh.
au niveau des syntaxes:
sh: sh, bash, zsh
c: zsh, tcsh, csh
k (mélange de csh/sh): ksh
Le shell n'est pas un language pour programmer à mon avis, mais plutot pour bidouiller le système, il est assez difficile de faire des programmes serieux en shell qui soit portable. En loccurence je développe une conf pour bash/ksh/tcsh/zsh qui utilise exactement les mêmes fichiers pour chaques shell, et chaque shell voir version de shell a ses spécificités, j'ai donc une library de fonction portable entre tous les shells.
Et toujours pour en revenir au problèmes principales pour les shells à mon avis, c'est la portabilité, et la donc la disponibilité par default d'un interpreteur sh sur tous les systemes. Sinon pour ce meme projet(il n'y as pas que la configuration des shells) j'aurai utilisé un autre language, et pas question non plus de distribuer des sources a compiler, car par exemple sous cygwin il n'y a pas forcement le compilo d'installé.
PS: le proj en question est www.sf.net/projects/grk
# Fonctionnalitées
Posté par CTAF . En réponse au journal Un meilleur shell. Évalué à 3.
Ensuite, on l'utilise pour des raisons historiques, bash est présent sur tous les systèmes, du moins on trouve forcement un interpreteur sh.
Ce qui facilite la vie des admins, c'est en partie pour ca que les autotools n'utilisent que des outils unix standard: la portabilité au détriment de la vitesse.
De plus il existe différent shell plus ou moins rapide avec des syntaxes plus ou moins différentes. De ce que tu decris tu as envi d'un équivalent du language c, utilise alors tcsh, csh, ou (celui que je prefere parmis tous) zsh.
au niveau des syntaxes:
sh: sh, bash, zsh
c: zsh, tcsh, csh
k (mélange de csh/sh): ksh
Le shell n'est pas un language pour programmer à mon avis, mais plutot pour bidouiller le système, il est assez difficile de faire des programmes serieux en shell qui soit portable. En loccurence je développe une conf pour bash/ksh/tcsh/zsh qui utilise exactement les mêmes fichiers pour chaques shell, et chaque shell voir version de shell a ses spécificités, j'ai donc une library de fonction portable entre tous les shells.
Et toujours pour en revenir au problèmes principales pour les shells à mon avis, c'est la portabilité, et la donc la disponibilité par default d'un interpreteur sh sur tous les systemes. Sinon pour ce meme projet(il n'y as pas que la configuration des shells) j'aurai utilisé un autre language, et pas question non plus de distribuer des sources a compiler, car par exemple sous cygwin il n'y a pas forcement le compilo d'installé.
PS: le proj en question est www.sf.net/projects/grk