Quel est le meilleur Shell ? Le plus puissant : Bash | Ksh ?

[Elise78]

Bonjour tout le monde

Je suis en train de migrer une application sous Oracle avec une plate-forme UNIX SCO et la je réalise mon plan de tests sous Linux Red Hat Enterprise Linux ES 3.0. Et voilà, je ne sais pas quel shell choisir ou si je garde celui que j'ai : bash.
Le point important c'est que je dois avoir le moins possible de modifications a faire pour la migration, si les autres shell sont aussi performants. Et la mon serveur UNIX SCO est en Korn shell.

Si vous avez des infos à ce sujet, ca pourrait bien m'aider, parce que je suis empetrée jusqu'au coup.

Merci d'avance.

Cordialement. Elise78

PS: Ce serait cool de ne pas me répondre Total (comment je peux avoir des idées pareilles des fois ? )

------------------------------------------------------

PS : Apparemment y'a pas foule pour mon soucis

[Elise78]

Et voilà j'ai enfin trouvé le type d'information dont j'avais besoin (pas encore assez précis mais c'est un bon début

Si ca interresse quelqu'un voilà ce que j'ai trouvé sur le Choix de l'interprète

Et ca donne ca (pour ce dont j'avais besoin) :

sh
Très adapté pour les petits scripts, qui sont très portables car sh existe sur quasiment toutes les plates-formes UNIX, il est extrêmement déconseillé pour les grands scripts ou la gestion d'arithmétique (elle n'est pas incluse dans le langage, il faut utiliser des programmes externes comme bc, ou expr pour les expressions simples). De plus, certains le considèrent comme peu fiable. En session interactive, ce shell est inutilisable.

bash
Ce shell, dérivé de sh, possède des fonctions interactives comparables à tcsh. Il est très répandu sous environnements Linux, notamment en raison de sa compatibilité avec la norme POSIX.

csh
A cause des nombreuses contradictions dans sa grammaire et les trop nombreuses mises à jour, ce shell ne devrait être utilisé que pour la session interactive, mais même pour cela, il est avantageusement remplacé par tcsh.

tcsh
Originellement, un excellent shell interactif, il est aujourd'hui avantageusement remplacé par bash.

ksh
Cette extension normalement compatible avec sh est suffisamment normalisée (POSIX), et, fait nouveau par rapport à sh, supporte les tableaux, et les valeurs numériques dans le langage. Pour la session interactive, relativement déconseillé.

[BZZz..]

Salut

Je connais pas bien les différents shells (perso j'utilise bash) mais 2 idées me viennent :
1) si ton appli est sous Oracle, passer d'un shell à l'autre ne devrait rien changer

sauf si...

2) si tu as des scripts en shell Korn (=ksh), autant garder ksh, normalement c'est là que tu auras le moins (voire rien du tout ) à réécrire.

Conclusion : si tout marche bien avec bash, la vie est belle...

De toute façon on peut toujours choisir le shell pour lequel un script est écrit : il faut rajouter en haut par exemple :

Code: Tout sélectionner

#!/bin/ksh

[Elise78]

Effectivement,

je n'ai pas qu'oracle (et Forms, Pro*C), j'ai aussi du script ... d'ailleurs pas mal de scripts sont lancés par ma crontab, et exécutés toute la nuit. Y'a un sacré volume. Pour le moment je dois faire les tests de migration sur un script qui prend à ce jour deux heures. Il est clair que réduire ce temps (par le choix du matériel aussi mais ca c'est déja prévu) par le biais de shell ca peut être tout bénef. D'ailleurs faut aussi que je pense que je vais encore migrer mon applicatif vers un langage proche du Web : comme par exemple python avec Zope ou MONO ...etc.

Je prends note de tes informations.

Alors si vous avez des infos sur un shell plus performant que les autres ou plus facile à migrer vers un langage de développement, Faites moi signe

[BZZz..]

hébin, tu vas pas avoir le temps de t'ennuyer...

Bon courage

[Elise78]

hébin, tu vas pas avoir le temps de t'ennuyer...

Bon courage

Tu ne crois pas si bien dire

[BZZz..]

un script qui prend à ce jour deux heures

ça c'est de la pause café ou je m'y connais pas




-----> [exit]

[cain]

Quelques informations se trouvent aussi ici : http://forums.ixus.net/viewtopic.php?t=19772

Cordialement,

Cain

[jdh]

Le korn shell est un shell utilisable sur tout système Linux (chercher ksh via rpmfind par exemple).

Le fichier /etc/password contient la liste des utilisateurs et ligne par ligne un certain nombre d'info dont la dernière est le shell à utiliser (la commande à lancer à la connexion de l'utilisateur).

Donc pour les utilisateurs identifiés tu peux remplacer /bin/bash par /bin/ksh.

Dans la crontab, tu lances des scipts qui doivent soit être lancés par /bin/ksh (avant le nom du script) soit les scripts sont executables (chmod +x) et ont en première ligne la notation #!/bin/ksh ce qui signifie qu'ils seront executés à l'invocation de leur nom au travers du shell indiqué.

Cette notation en première ligne s'applique à d'autres choses que le shell : par exemple awk, ...

[Elise78]

Bonjour tout le monde !!

Je cherche les renseignements clairs sur les différences entre les commandes Shell
(bash pour Linux et csh ou ksh ou UNIX SCO), sous forme de liens ou de documents,
pour une migration de code d'UNIX SCO vers Linux RedHat.

Merci d'avance.

Cordialement, Melle Elise78.

[Gaston]

Bonjour,

évite de mélanger les OS et les shells.
C'est pas parce que Linux utilise de base le BourneAgainShell qu'il faut dire linux=bash (combien de fois je tape : "ksh -o vi " pour me retouver dans mes baskets ? )

Pour les comparaisons, tu trouveras tous les trolls (et le bonnes informations) possibles sur : [url=news:comp.unix.shell]news:comp.unix.shell[/url]
juste un conseil avant de poster, lis les FAQ, et au moins deux mois de posts (oui je sait ça va faire des nuits blanches, mais ça t'évitera de te faire jeter au premier post).
Google est vraiment ton amis dans l'histoire (n'oublie pas que tu peux chercher sur les newsgroup, et pas que les pages web)

Juste pour finir , un avis :
en tant qu'utilisateur de ligne de commande, je passe de bash à ksh sans trop de soucis mais je dois pas utiliser plus de 10 % des fonctionnalités.
tous mes scripts (simples > 500 lignes) je les fait pour du /bin/sh : ça peut être plus lourd, plus lent, plus long à écrire, mais c'est portable.
j'aime pas csh, c'est vraiment personnel.
en bash ou ksh tu peux vraiment écrire beaucoup de choses et si tu te trouves limitée, passe à du awk, ou fait les suat vers perl : c'est portable (en plus le perl si tu as des idées d'inter/ra net ) et tu trouveras des mines d'infos sur le net.

tout script peut s'exécuter sur plusieurs systèmes : il suffit d'éviter certains éccueils (différences de paths, de commandes, de paramètres par exemple : "tar tvf" est compris par le GNUTar sur linus et autres systèmes, ailleurs, il faut "tar -tvf" (qui est aussi compris pas le GnuTar d'ailleurs ...) c'est pas un probkème de shell ;( )

Bon courage
Gaston

[Elise78]

Salut Gaston,

Il ne me semble pas mélanger les OS et les shells, j'ai opté pour un rapprochement facile je te l'accorde, mais pas du tout une confusion.

tout script peut s'exécuter sur plusieurs systèmes :

Vu les soucis qu'à mon code à s'exécuter convenablement sans modifs, j'en doute un peu ... ca doit surement etre du aux parametres d'ailleurs ...
Et justement dans ce but que je me demande lequel est le meilleur : garder ksh parce que les scripts sont deja en l'état ou changer pour optimiser les performances ?

Merci, pour les infos.

Cordialement, Melle Elise78

[Gaston]

re,

Et justement dans ce but que je me demande lequel est le meilleur : garder ksh parce que les scripts sont deja en l'état ou changer pour optimiser les performances ?

je veux vraiment pas partir dans un troll, ma reflexion est la suivante :

o tu dois développer de nouveau scripts : choisi celui qui te plait le mieux.

o tu as déjà tes scripts en ksh : gardes les, met juste à jour les parties qui ne sont pas compatibles entre la version ksh que tu as sur ton SCO et celle que tu as sur la RH ES 3 (@(#)$%#&! KSH v5.2.14 99/07/13.2)

et revois petit à petit tes scripts pour les améliorer.

Là où tu peux trouver des loups c'est dans le codage d'appel à des fonctions bizarres très liées à SCO, sinon je ne vois pas (genre éviter les super > &- , dont tu ne te rappelleras pas dans un an que c'était un > /dev/null ) quels sont les forks, les appels systèmes, les passages de variables ...

Qu'est-ce que tu fais avec tes scripts ? t'es vraiment sure que c'est le script qui est long ?

A mon avis ce n'est pas sur le choix de l'interpréteur que tu vas gagner en perf. J'ai expérimenté des différences de perfs entre différentes versions de perl, mais pas au niveau de l'interpréteur de commandes.
Tout ce que j'ai pu lire dans le newsgroup cité (il y a qques temps déjà) se référait plus aux différences dans les fonctionnalités : évalutation d'une commande , ...
moi je vois pas la différence entre toto=`ps` et toto=$(PS) - c'est imaginaire je sait pas si c'est qqchse de valide mais le principe est là -

Regarde le newsgroup, étudie les conseils, (mauvaise usage du "cat" par exemple).

Fais toi une idée en réécrivant un bout de test script en bash et compare le temps avec la version ksh
( time mon_script.ksh // time mon_script.bash)

C'est à toi de faire le choix: tu réécris tout ou tu corriges : ça dépend du temps que tu as, de tes compétences (désolé mais c'est un critère réél ce n'est pas un jugement), du coût et de tes affinités pour l'un ou l'autre des shells.
L'important c'est d'avoir à la fin qqchse de maintenable, documenté et qui fonctionne bien sur.

Tout ce qu eje peux te donner xomme indication, c'est que à ma boîte tous les scripts de gestion des bases oracle sont en ksh (start / stop / rman / logs / reprise sur incidents / ... )

G.