Cela dit, la coquille Korn - en tant que chose distincte de la coquille POSIX - n'est jamais vraiment devenue populaire en dehors du monde commercial Unix. Ceci est dû au fait que son ascension correspond aux premières années de la commercialisation d’Unix et qu’il a donc été pris dans les guerres d’Unix . BSD Unixes l’évitait en faveur du shell C, et son code source n’était pas librement disponible pour l’utilisation de Linux lorsqu’il a été lancé. »Ainsi, lorsque les premiers distributeurs Linux ont cherché un shell de commande pour leur noyau Linux, ils ont généralement choisi GNU Bash , l’une de ces sh
incompatibles dont vous parlez. »
Cette association précoce entre Linux et Bash a en quelque sorte scellé le destin de nombreux autres shell, y compris ksh
, csh
et tcsh
. Il y a des durs qui utilisent encore ces coquilles aujourd'hui, mais ils sont très minoritaires. »
Toute cette histoire explique pourquoi les créateurs de retardataires relatifs aiment bash
, zsh
et ont yash
choisi de les rendre sh
compatibles: la compatibilité Bourne / POSIX est le minimum qu'un shell pour les systèmes de type Unix doit fournir pour une adoption généralisée.
J'ai utilisé le terme "script shell" ci-dessus comme terme générique qui signifie "script shell Bourne / POSIX". Cela est dû à l'omniprésence des coquillages de la famille Bourne. Pour parler de la création de scripts sur d'autres shells, vous devez donner un qualificatif, tel que "script C". Même sur les systèmes où un shell de la famille C est le shell interactif par défaut, il est préférable d'utiliser le shell Bourne pour les scripts.
Il existe de nombreuses façons de vérifier si un script shell de la famille Bourne est portable:
Les premières versions de BSD Unix n'étaient que des collections de logiciels complémentaires pour V6 Unix. Etant donné que le shell Bourne n’a été ajouté à AT & T Unix qu’après la V7, BSD n’a pas techniquement commencé avec le shell Bourne. La réponse de BSD à la nature primitive de la coquille Thompson était la coque C .
Néanmoins, les premières versions autonomes de BSD (et de 2.9BSD 3BSD) étaient basées sur V7 ou son successeur portable UNIX / 32V , donc ils l'ont fait inclure le shell Bourne.
(La ligne 2BSD transformé en une fourchette parallèle de BSD pour de Digital de mini - ordinateurs PDP , tandis que les lignes 3BSD et 4BSD ont continué à tirer profit des types d'ordinateurs plus récents comme VAX et les stations de travail Unix 2.9BSD était essentiellement la version PDP de 4.1cBSD;. Ils étaient contemporaine, et le code partagé . PDPs ne disparaissent pas lorsque le VAX est arrivé, de sorte que la ligne 2BSD est toujours traînante le long .)
Il est juste de dire que le shell Bourne était partout dans le monde Unix en 1983. C'est une bonne approximation de "pour toujours" dans l'industrie informatique. MS-DOS a obtenu un système de fichiers hiérarchique cette année-là (ainsi que le premier Macintosh 24 bits avec son écran 9 "N & B - ni en niveaux de gris, ni en noir et blanc - ne sortira pas avant le début de l'année prochaine.
La coquille Thompson était assez primitive par rapport aux normes actuelles. Ce n'était qu'un shell de commande interactif, plutôt que l'environnement de programmation de script que nous attendons aujourd'hui. Il contenait des éléments tels que les tuyaux et la redirection d'entrée / sortie, que nous considérons comme faisant partie du prototype d'un "shell Unix", de sorte que nous pensons que le shell de commande MS-DOS les extrait d'Unix.
Le shell Bourne a également remplacé le shell PWB , ce qui a ajouté des éléments importants au shell Thompson, tels que la programmabilité ( if
, switch
et while
) et une forme précoce de variables d’environnement. Le shell PWB est encore moins connu que le shell Thompson puisqu'il ne faisait pas partie de toutes les versions d'Unix.
Lorsque quelqu'un n'est pas spécifique à propos de la compatibilité entre le shell POSIX et Bourne, il peut entendre toute une gamme de choses.
À un extrême, ils pourraient utiliser le Bourne 1979 comme base de référence. Un « sh
scénario compatible » dans ce sens signifierait qu'il devrait fonctionner parfaitement sur la coquille vraie Bourne ou l' un de ses successeurs et clones: ash
, bash
, ksh
, zsh
, etc.
À l’autre extrémité, une personne assume le shell spécifié par POSIX comme référence. De nos jours, nous prenons tellement de fonctionnalités "standard" dans le shell POSIX que nous oublions souvent qu’elles n’étaient pas réellement présentes dans le shell Bourne: arithmétique intégrée, contrôle des tâches, historique des commandes, alias, modification de ligne de commande, $()
forme de commande substitution, etc.
Bien que le shell Korn ait des racines remontant au début des années 1980, AT & T ne l’a pas expédié sous Unix jusqu’à System V Release 4 en 1988. Étant donné que tant d’Unix commerciaux sont basés sur SVR4, cela inclut ksh
pratiquement tous les Unix commerciaux pertinents du fabricant. fin des années 1980.
(Quelques saveurs Unix étranges basées sur SVR3 et antérieures se sont maintenues sur des morceaux du marché après la sortie de SVR4, mais elles étaient les premières contre le mur lorsque la révolution est survenue.)
1988 est également l'année de la publication du premier standard POSIX , avec son "shell POSIX" basé sur le shell Korn. Plus tard, en 1993, une version améliorée du shell Korn est sortie. Depuis que POSIX a efficacement cloué l’original en place, il a ksh
été divisé en deux versions majeures: ksh88
et ksh93
, du nom des années impliquées dans leur scission.
ksh88
n'est pas entièrement compatible POSIX, bien que les différences soient minimes, de sorte que certaines versions du ksh88
shell ont été corrigées pour être compatibles POSIX. (Ceci est tiré d'une interview intéressante sur Slashdot avec le Dr. David G. Korn . Oui, le gars qui a écrit la coquille.)
ksh93
est un sur-ensemble entièrement compatible du shell POSIX . Le développement sur ksh93
a été sporadique depuis que le référentiel source principal a été transféré d’AT & T à GitHub, la version la plus récente datant d’environ 3 ans, ksh93v. (Le nom de base du projet reste ksh93
avec des suffixes ajoutés pour indiquer les versions publiées au-delà de 1993.)
Les systèmes qui incluent un shell Korn en tant que composant distinct du shell POSIX le rendent généralement disponible /bin/ksh
, même si parfois il se cache ailleurs.
Lorsque nous parlons de nom ksh
ou de shell Korn, nous parlons de ksh93
fonctionnalités qui le distinguent des sous-ensembles de shell Bourne et POSIX rétrocompatibles. Vous rencontrez rarement le pur ksh88
aujourd'hui.
AT & T a conservé le code source du shell Korn jusqu'en mars 2000 . À ce stade, l'association de Linux avec GNU Bash était très forte. Bash et ksh93
chacun ont des avantages sur l’autre , mais à ce stade, l’inertie maintient Linux étroitement associé à Bash.
Quant aux raisons pour lesquelles les premiers fournisseurs de Linux optaient le plus souvent pour GNU Bash pdksh
, qui était disponible au moment du démarrage de Linux, je suppose que c'est parce qu'une grande partie du reste de l'espace utilisateur provient également du projet GNU . Bash est également un peu plus avancé que celui-ci pdksh
, car les développeurs de Bash ne se limitent pas à la copie des fonctionnalités du shell Korn.
Les travaux ont pdksh
cessé à peu près au moment où AT & T a publié le code source dans le véritable shell Korn. Il y a deux fourches principales qui sont encore maintenus, cependant: OpenBSD pdksh
et le MirBSD Korn Shell,mksh
.
Je trouve intéressant que ce mksh
soit la seule implémentation de shell Korn actuellement intégrée dans Cygwin.
GNU Bash va au-delà de POSIX à bien des égards, mais vous pouvez lui demander de fonctionner dans un mode POSIX plus pur .
csh
/ tcsh
était généralement le shell interactif par défaut de BSD Unix au début des années 1990.
En tant que variante BSD , les premières versions de Mac OS X étaient ainsi, via Mac OS X 10.2 "Jaguar" . OS X a changé le shell par défaut de tcsh
Bash dans OS X 10.3 "Panther" . Cette modification n'a pas affecté les systèmes mis à niveau à partir de la version 10.2 ou antérieure. Les utilisateurs existants sur ces systèmes convertis ont conservé leur tcsh
shell.
FreeBSD prétend continuer à utiliser tcsh
le shell par défaut , mais sur la machine virtuelle FreeBSD 10 que j'ai ici, le shell par défaut semble être l'une des variantes de shell Almquist compatibles POSIX . Ceci est également vrai sur NetBSD.
OpenBSD utilise un fork de pdksh
comme shell par défaut.
La popularité accrue de Linux et OS X incite certaines personnes à souhaiter que FreeBSD passe également à Bash, mais cela ne sera pas le cas pour des raisons philosophiques . Il est facile de le changer si cela vous dérange.
Il est rare de trouver un système avec un shell Bourne vraiment vanillé comme /bin/sh
ces jours-ci. Vous devez faire tout votre possible pour trouver quelque chose d'assez proche pour le test de compatibilité.
Je ne connais qu'un seul moyen de gérer un véritable shell Bourne de 1979 sur un ordinateur moderne: utilisez les images de disque Ancient Unix V7 avec le simulateur SIMH PDP-11 du projet Computer History Simulation . SIMH fonctionne sur pratiquement tous les ordinateurs modernes , pas seulement ceux de type Unix. SIMH fonctionne même sur Android et iOS .
Avec OpenSolaris , Sun a ouvert pour la première fois la version SVR4 du shell Bourne. Auparavant, le code source des versions post-V7 du shell Bourne n’était disponible que pour ceux qui détenaient une licence de code source Unix.
Ce code est maintenant disponible séparément du reste du projet obsolète OpenSolaris à partir de plusieurs sources différentes.
La source la plus directe est le projet de shell Heirloom Bourne . Cela est devenu disponible peu de temps après la version 2005 d'OpenSolaris. Certains travaux de portabilité et de correction des bogues ont été effectués au cours des prochains mois, mais le développement du projet s’est arrêté.
Jörg Schilling a fait un meilleur travail en maintenant une version de ce code comme osh
dans son paquet Schily Tools . Voir ci-dessus pour plus d'informations à ce sujet.
N'oubliez pas que ces shells dérivés de l'édition de code source 2005 contiennent un support de jeu de caractères multi-octets , un contrôle des travaux, des fonctions de shell et d'autres fonctionnalités non présentes dans le shell Bourne original de 1979.
Une façon de savoir si vous utilisez ou non un shell Bourne original est de voir s'il prend en charge une fonctionnalité non documentée ajoutée pour faciliter la transition depuis le shell Thompson: ^
comme alias pour |
. C'est-à-dire qu'une commande comme ls ^ more
va donner une erreur sur un shell de type Korn ou POSIX, mais se comportera comme ls | more
sur un vrai shell Bourne.
Parfois , vous rencontrez un fish
, scsh
ou rc/es
adhérent, mais ils sont encore plus rares que les fans de shell C.
La rc
famille de shells n'est pas couramment utilisée sur les systèmes Unix / Linux, mais elle est historiquement importante, ce qui explique sa place dans le diagramme ci-dessus. rc
est le shell standard du système d'exploitation Plan 9 de Bell Labs , une sorte de successeur de la 10e édition d'Unix , créé dans le cadre de la recherche continue de Bell Labs sur la conception du système d'exploitation. Il est incompatible avec Bourne et C shell au niveau de la programmation. il y a probablement une leçon dedans.
La variante la plus active de rc
semble être celle maintenue par Toby Goodwin , basée sur le rc
clone Unix de Byron Rakitzis.
sh
). Pour un shell différent, cela indique si ce shell peut ou non exécuter les scripts du shell Bourne.