Pourquoi personne n'utilise le véritable shell Bourne comme / bin / sh?

J'ai remarqué qu'au fond, aucun système avec /bin/sh n'a fonctionné comme un vrai exécutable. C'est toujours un lien symbolique à dash , bash en mode POSIX, ou quelque chose de similaire.

Pourquoi? Quels sont les inconvénients de l'utilisation du vrai, original /bin/sh ? (Vitesse? Licences?)

    Je suppose que le manque de fonctionnalités – pas d'historique des commands, pas de redirection de fantaisie, pas de modification en command line. BSD a introduit csh le shell C pour ces raisons. Un autre facteur est que le Genuine Bourne Shell n'était disponible que récemment sous forme de code source ouvert . Sauf si vous l'avez sous licence, vous ne pouvez pas le dissortingbuer. Cela a mis hors de scope pour les dissortingbutions gratuites et l'a rendu idéologiquement désagréable pour d'autres dissortingbutions, et * BSDs.

    Mais le code est disponible maintenant. Vous pouvez jeter un oeil, le comstackr, lui donner un tour.

    L'énoncé de votre question est incorrect. Solaris jusqu'à la version 10 fournit l'ancien shell Bourne hérité sous /bin/sh . Cela a été fait pour ne pas rompre la compatibilité avec les anciens scripts qui pourraient échouer avec un shell différent. Ce choix était très frustrant sinon.

    La plupart, sinon toutes les versions restantes d'Unix et d'Unix, y compris Solaris 11, fournissent un shell POSIX compatible avec /bin/sh car POSIX mandate la command sh pour lancer un shell POSIX et non le shell Bourne qui n'est pas conforme. /bin/sh est généralement:

    • ksh88 ou ksh93 sur les implémentations Unix commerciales
    • un bash modifié sur OS/X (bien qu'il ait été zsh )
    • un dérivé ash ou pdksh sur d'autres BSDs
    • bash ou dash sur les dissortingbutions Gnu / Linux.

    Ce n'est pas forcément un lien mais peut être un vrai exécutable sur de nombreux systèmes mais Gnu / Linux.

    Il est intéressant de noter que ce n'est pas le manque de fonctionnalités qui conduit les développeurs de dissortingbution à installer quelque chose de différent de l'ancien shell Bourne dans /bin/sh mais le désir d'être aussi conforme POSIX que possible se comporter comme Unix comme OS. Le fait que le shell POSIX possède plus de fonctionnalités que l'ancien shell Bourne n'est qu'un effet secondaire de cet objective de conformité standard.

    C'est aussi un fait que certains shells, notamment bash , se comportent différemment lorsqu'ils sont appelés sh , ce qui supprime surtout les caractéristiques de la coquille, et non l'inverse.

    Pour autant que je sache, le shell Bourne d'origine ne pouvait pas être utilisé par les BSD et le projet GNU, en raison de sa licence.

    À l'époque, l'original Unix n'avait pas de licence et le projet GNU avait besoin d'un shell qui était sous la GPL, donc ils ont utilisé le bash.

    La même chose est vraie pour BSD4 le parent de tous les BSD. Merci à la poursuite AT & T, ils avaient besoin de réécrire toutes les sources de l'original, y compris le shell Bourne.

    Dans la ligne BSD traditionnelle, le shell Bourne a été embarqué jusqu'à 4.3BSD-Reno (mais pas plus avec Net / 2 et les 4.4BSD suivants). Pour des raisons de licence, il a ensuite été remplacé par le shunt de type svr4 compatible avec le bourne de Kenneth Almquist (souvent appelé ash).

    De FreeBSDs man sh

    Une command sh, le shell Thompson, est apparue dans la version 1 d'AT & T UNIX. Il a été remplacé dans la version 7 AT & T UNIX par le shell Bourne, qui a hérité du nom sh.

    Cette version de sh a été réécrite en 1989 sous la licence BSD après le shell Bourne d'AT & T System V Release 4 UNIX

    Les deux projets ont donc été contraints de ne pas utiliser le shell Bourne et de se contenter d'un véritable shell open source.

    Il y a eu d'autres problèmes. Le Bourne Shell a utilisé sbrk () au lieu de malloc () et cela n'a pas rendu très portable.

    Après le Bourne Shell était devenu OpenSource via OpenSolaris, j'ai créé une version portable hafway et plus tard une version vraiment portable en remplaçant sbrk () par malloc () avec l'aide de Geoff Collyer (la même personne qui a aidé à éviter sbrk Korn Shell).

    La raison initiale, pourquoi j'ai fait une version portable du Bourne Shell est que j'ai aimé faire l'éditeur d'histoire que j'ai écrit pour mon "bsh" entre 1982 et 1984 disponible dans le Bourne Shell aussi. Pendant ce time, j'ai porté la plupart des caractéristiques uniques que j'ai écrites pour "bsh" à la Bourne Shell.

    C'est entre autres:

    • Comstack et travaille presque partout, y compris Cygwin (presque 2x plus vite que bash)
    • L'éditeur d'historique avec un tampon d'anneau LRU
    • embedded TERMCAP
    • Les alias avancés (alias persistants globaux, alias locaux, ….) et avec le "dosh" embedded, le Bourne Shell est la seule implémentation de Bourne Shell qui autorise les alias paramétrables.
    • Support pour éditer des alias complexes dans l'éditeur d'historique en mode brut.
    • Accédez à tous les 32 bits du code de sortie (2) via des variables .sh. *.
    • timing automatisé avancé avec une résolution de 6 numbers
    • pushd / popd / dirs
    • builtin "find"
    • Pipe de stderr
    • Utilisation de vfork () pour de meilleures performances.
    • enfin corrigé tous les bugs documentés du SVr4 Bourne Shell, par exemple suspendre fonctionne toujours en mode contrôle de travail. …

    La page de man en ligne est à: http://schillix.sourceforge.net/man/man1/bosh.1.html Les sources font partie de la boîte à outils schily à:

    https://sourceforge.net/projects/schilytools/files/

    Je recommand d'utiliser: http://sourceforge.net/projects/schilytools/files/schily-2015-08-18.tar.bz2 ou une version plus récente.

    PS Je suis intéressé par les commentaires

    Il est lié aux coquilles qui offrent une compatibilité descendante de 100%. Vous ne perdez rien de ce que le shell d'origine a mais gagnez plus de fonctionnalités dessus. Il n'y a aucun inconvénient, alors pourquoi ne pas profiter des nouvelles fonctionnalités? C'est la même raison pour laquelle /bin/vi est généralement lié à vim .