Le premier souci du développeur de shell script doit être la portabilité. En effet, il est dispendieux d'avoir à réadapter des procédures d'exploitation à chaque introduction d'une nouvelle machine. Les scripts développés sur une architecture d'un constructeur sous le même système d'exploitation (UNIX), doivent se comporter de façon identique sur SunOS, Solaris, HP-UX, Irix, Digital UNIX, AIX, etc. La normalisation POSIX est là pour le permettre.
Les développements ne doivent pas être des opérations où l'on redécouvre et reconstruit la roue. Un usage systématique des utilitaires ad-hoc (de la « section 1 ») est recommandé. Quand cela s'avère nécessaire pour les traitements de données symboliques, on utilisera en priorité les utilitaires de manipulation de fichiers.
On limitera volontairement l'usage des utilitaires « sed » et « awk » à des séquences simples de traitement, dès l'instant où l'on a recours à des expressions régulières. Décomposez les traitements à effectuer. Exploitez la philosophie et les possibilités d'UNIX :
Il est beaucoup plus économique d'utiliser plusieurs commandes qui s'enchaînent (avec les mécanismes des pipes) pour réaliser une tâche complexe. Vous y gagnerez en simplicité de raisonnement et de mise au point.
N'oubliez pas que le C Shell, le TC Shell, le Bourne Another Shell (ou bash) et le Korn Shell exécutent, à chaque lancement, les fichiers suivants :
| Shell | Fichier |
| C Shell | ~/.cshrc |
| TC Shell | ~/.tcshrc |
| Bourne Another Shell | ~/.bashrc |
| Korn Shell | ~/.kshrc |
Par conséquent, à chaque lancement d'un script C Shell, TC Shell, Bourne Another Shell (ou bash) ou Korn Shell, le fichier d'initialisation est exécuté par défaut.