Bash ou KornShell (ksh)? [fermé]

Question

Je ne suis pas nouveau dans * nix, mais depuis peu, je passe beaucoup de temps à l’invite. Ma question est la suivante: quels sont les avantages d’utiliser KornShell (ksh) ou Bash Shell? Où sont les pièges d'utiliser l'un sur l'autre?

Rechercher pour comprendre du point de vue d'un utilisateur, plutôt que de simples scripts.

Answer 1

Bash.

Les diverses implémentations UNIX et Linux ont différentes implémentations de ksh au niveau source, dont certaines sont de véritables ksh, certaines d’implémentations pdksh et d’autres juste des liens symboliques vers un autre shell ayant le symbole "ksh". personnalité. Cela peut entraîner des différences étranges dans le comportement d'exécution.

Au moins, avec bash, vous pouvez être sûr qu’il s’agit d’une base de code unique. La seule chose dont vous avez besoin est de savoir quelle version (généralement minimale) de bash est installée. Ayant beaucoup travaillé sur chaque UNIX moderne (et pas si moderne), la programmation de bash est plus cohérente, selon mon expérience.

Answer 2

La différence entre Kornshell et Bash est minime. Il y a certains avantages l'un sur l'autre, mais les différences sont minimes:

• BASH est beaucoup plus facile de définir une invite qui affiche le répertoire actuel. Faire la même chose à Kornshell est hackish.
• Kornshell a des tableaux associatifs, pas BASH. La dernière fois que j’ai utilisé des tableaux associatifs, c’était ... Laissez-moi réfléchir ...
• Kornshell gère un peu mieux la syntaxe de la boucle. Vous pouvez généralement définir une valeur dans une boucle Kornshell et la laisser disponible après la boucle.
• Bash gère l’obtention des codes de sortie des pipes de manière plus propre.
• Kornshell a la commande print qui est bien meilleure que la commande echo .
• Bash a des onglets terminés. Dans les anciennes versions
• Kornshell a la commande r history qui me permet de réexécuter rapidement les commandes plus anciennes.
• Kornshell a la syntaxe cd old new qui remplace old par new dans votre répertoire et vos CD-ROM. C'est pratique lorsque vous vous trouvez dans un répertoire nommé / foo / bar / barfoo / one / bar / bar / foo / bar et que vous devez vous connecter à / foo / bar / barfoo / two / bar / bar / foo / bar Dans Kornshell, vous pouvez simplement faire cd un deux et en finir avec cela. Dans BASH, vous devez cd ../../../../../ two / bar / bar / foo / bar .

Je suis un vieil homme de Kornshell parce que j’ai appris Unix dans les années 90 et que c’était la coque de choix à l’époque. Je peux utiliser Bash, mais je suis parfois frustré parce que, comme d'habitude, j'utilise une fonctionnalité mineure que Kornshell a que BASH n'a pas et que cela ne fonctionne pas. Donc, dans la mesure du possible, je règle Kornshell comme paramètre par défaut.

Cependant, je vais vous dire d’apprendre BASH. Bash est maintenant implémenté sur la plupart des systèmes Unix, ainsi que sur Linux, et il existe tout simplement plus de ressources disponibles pour apprendre BASH et obtenir de l'aide que Kornshell. Si vous avez besoin de faire quelque chose d'exotique dans BASH, vous pouvez aller sur Stackoverflow, poser votre question et vous obtiendrez une douzaine de réponses en quelques minutes - et certaines d'entre elles seront même correctes!.

Si vous avez une question sur Kornshell et que vous la postez sur Stackoverflow, vous devrez attendre que le vieux pirate tel qu’il se trouve ait passé, comme moi, me réveille de sa sieste avant d’obtenir une réponse. Et oubliez toute réponse s'ils servent du pudding dans la maison de retraite ce jour-là.

BASH est tout simplement la coque de choix à présent, alors si vous devez apprendre quelque chose, faites-le aussi bien avec ce qui est populaire.

Answer 3

Je suis un ancien combattant de korn-shell, alors sachez que je parle dans cette perspective.

Cependant, je suis à l'aise avec Bourne Shell, ksh88 et ksh93, et je sais pour la plupart quelles fonctionnalités sont prises en charge. (Je devrais ignorer ksh88 ici, car il n'est plus largement distribué.)

Pour une utilisation interactive, prenez ce qui vous convient. Expérience. J'aime pouvoir utiliser le même shell pour une utilisation interactive et pour la programmation.

Je suis passé de ksh88 sur SVR2 à tcsh, à ksh88sun (qui a ajouté un support important en matière d’internationalisation) et ksh93. J'ai essayé bash et je l'ai détesté parce que cela a aplati mon histoire. Ensuite, j'ai découvert le lithographe de shopt -s et tout allait bien. (L’option lithist garantit que les nouvelles lignes sont conservées dans votre commande. histoire.)

Pour la programmation shell, je recommanderais sérieusement ksh93 si vous voulez un langage de programmation cohérent, une bonne conformité POSIX et de bonnes performances, car de nombreuses commandes unix courantes peuvent être disponibles en tant que fonctions intégrées.

Si vous voulez la portabilité, utilisez au moins les deux. Et assurez-vous d'avoir une bonne suite de tests.

Il existe de nombreuses différences subtiles entre les coquilles. Considérons par exemple la lecture d'un tuyau:

b=42 && echo one two three four |
    read a b junk && echo $b

Cela produira des résultats différents dans différentes coques. Le korn-shell gère les pipelines de l'arrière vers l'avant; le dernier élément du pipeline est exécuté dans le processus en cours. Bash n’a pas supporté ce comportement utile jusqu’à la version v4.x, et même dans ce cas, ce n’est pas le comportement par défaut.

Autre exemple illustrant la cohérence: la commande echo elle-même, rendue obsolète par la scission entre BSD et SYSV unix, et chacune a introduit sa propre convention pour ne pas imprimer de nouvelles lignes (et autres comportements). Le résultat de ceci peut encore être vu dans beaucoup de scripts 'configure'.

Ksh a adopté une approche radicale à cet égard - et a introduit la commande print , qui prend en charge les deux méthodes (l'option -n de BSD) et le dernier . \ c caractère spécial de SYSV)

Cependant, pour la programmation système sérieuse, je recommanderais autre chose qu'un shell, comme python, perl. Ou allez plus loin et utilisez une plate-forme comme marionnette, qui vous permet de surveiller et de corriger l’état de grappes entières de systèmes, avec un bon audit.

La programmation de Shell est comme nager dans des eaux inexplorées, ou pire.

La programmation dans n’importe quel langage nécessite une connaissance de sa syntaxe, de ses interfaces et de son comportement. La programmation shell n’est pas différente.

Answer 4

Je n'ai pas d'expérience avec ksh, mais j'ai utilisé à la fois bash et zsh. Je préfère zsh à bash en raison de sa prise en charge de la suppression de fichiers très puissante, de ses modificateurs d'expansion variables et de la rapidité d'exécution des onglets.

Voici une introduction rapide: http://friedcpu.wordpress.com/2007/07/24/zsh-the-last-shell-youll-ever-need/

Answer 5

C'est un peu une bataille entre Unix et Linux. La plupart des distributions Linux, sinon toutes, ont bash installé et ksh est facultatif. La plupart des systèmes Unix, tels que Solaris, AIX et HPUX, utilisent ksh par défaut.

Personnellement, j’utilise toujours ksh, j’adore l’achèvement de vi et j’utilise quasiment Solaris pour tout.

Answer 6

Pour les scripts, j'utilise toujours ksh car cela adoucit les pièges .

Mais je trouve bash plus confortable pour une utilisation interactive. Pour moi, les principaux avantages sont les raccourcis clavier emacs . Mais c’est surtout une habitude, pas un problème technique avec ksh .

Answer 7

@foxxtrot

En fait, le shell standard est Bourne Shell ( sh ). / bin / sh sous Linux est en réalité bash , mais si vous visez des scripts multiplates-formes, il est préférable de vous en tenir aux fonctionnalités du shell Bourne d'origine ou l'écrire dans quelque chose comme perl .

Answer 8

Ma réponse serait: "Choisissez-en un et apprenez à vous en servir". Ce sont deux coquilles décentes; bash a probablement plus de cloches et de sifflets, mais ils ont tous les deux les fonctionnalités de base dont vous avez besoin. bash est plus universellement disponible ces jours-ci. Si vous utilisez Linux tout le temps, restez-y.

Si vous programmez, essayez de vous en tenir à la portabilité, c'est une bonne pratique, mais avec un bash disponible si largement de nos jours, ce conseil est probablement un peu démodé.

Découvrez comment utiliser la complétion et votre historique de shell. Lisez la page de manuel de temps en temps et essayez d'apprendre quelques nouvelles choses.

Answer 9

Premièrement, bash a terminé la tabulation Cela suffit à me faire préférer ksh.

Le shell Z combine les fonctionnalités uniques de ksh avec les fonctionnalités intéressantes proposées par bash, et bien plus encore. des trucs en plus de ça.

Answer 10

Disponible dans la plupart des systèmes UNIX, ksh est conforme à la norme, clairement conçu et complet. Je pense que les livres, aide en ksh est suffisant et clair, en particulier le livre O'Reilly. Bash est une masse. Je le conserve en tant que shell de connexion root pour Linux à la maison uniquement.

Pour une utilisation interactive, je préfère zsh sous Linux / UNIX. J'exécute les scripts en zsh, mais je vais tester la plupart de mes scripts, mais en ksh sous AIX.

Answer 11

Bash est la référence, mais c’est principalement parce que vous pouvez être raisonnablement sûr qu’il est installé sur chaque * nix. Si vous envisagez de distribuer les scripts, utilisez Bash.

Je ne peux malheureusement pas aborder les différences de programmation réelles entre les coques.

Answer 12

Bash est la norme pour Linux.
D'après mon expérience, il est plus facile de trouver de l'aide pour bash que pour ksh ou csh.