Choix de l'interprète

Le choix de l'interprète approprié pour une tâche donnée n'est évidemment pas universel. Cependant, les programmeurs shell expérimentés font les constatations suivantes:

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é.

perl

Ce langage (non interactif) a l'avantage d'offrir beaucoup de fonctions qui augmentent la vitesse de l'ensemble. On pourrait le comparer à une sorte de C interprété. Il offre aussi des possibilités étendues de sécurité, particulièrement en ce qui concerne les fameux suid scripts. Malheureusement, beaucoup le considèrent comme étant write-only: en effet sa syntaxe est quelque peu primitive.

awk

Ce langage (non interactif) sert surtout au traitement de données représentées sous forme de champs textuels.

Il faut noter que même si la création de scripts est souvent plus simple que la programmation en un langage tel que C, et parfois plus portable, les scripts sont exécutés de façon très lente en raison surtout des nombreuses commandes externes exécutées. Un compromis entre le temps de développement et le coût à l'exécution doit être trouvé.