Pourquoi personne n'utilise le vrai shell Bourne en tant que / bin / sh?

55

J'ai remarqué qu'aucun système avec lequel j'ai travaillé n'avait /bin/shun véritable exécutable. C'est toujours un lien symbolique vers dash, bashen mode POSIX, ou quelque chose de similaire.

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

shell history dash combattant
la source
3
Vous avez seulement utilisé Linux, n'est-ce pas? Je n'ai jamais vu "sh as symlink" sous Linux.
Greg Hewgill
@GregHewgill Les versions récentes de Solaris n'ont- shelles pas un lien symbolique vers ksh?
Gilles 'SO- arrête d'être méchant'
1
@Gilles selon l'une des réponses, oui, depuis Solaris 11. C'est lié à ksh.
Strugee
1
@GregHewgill J'ai aussi utilisé Darwin, qui a un lien symbolique vers bashIIRC.
Strugee
6
Qu'entendez-vous par l' original / bin / sh ? Le shell Thomson sous Unix V1? Le shell Bourne de Unix V7 qui n’a pas de fonctions pas de commentaires ...? Celui de SysIII, SysV, Solaris, HP / UX, la réimplémentation des cendres sur les BSD? De nos jours shest basé sur un standard, ce qui signifie que nous pouvons avoir plusieurs implémentations qui se comporteront de manière claire et précise tant que vous utiliserez la syntaxe standard dans votre script.
Stéphane Chazelas

Réponses:

38

Je suppose que le manque de fonctionnalités - pas d’historique des commandes, pas de redirection sophistiquée, pas d’édition en ligne de commande. BSD a introduit cshle shell C pour ces raisons. Un autre facteur est que Genuine Bourne Shell n'était disponible que récemment sous forme open source . Sauf si vous avez obtenu une licence, vous ne pouvez pas le distribuer. Cela l'a mis hors de portée des distributions gratuites et l'a rendu idéologiquement désagréable pour d'autres distributions et * BSD.

Mais le code est disponible maintenant. Vous pouvez jeter un coup d'oeil, le compiler, l'essayer.

Bruce Ediger
la source
50
Et puis revenez rapidement à ce que vous utilisiez auparavant.
Ignacio Vazquez-Abrams
24
@strugee "" manque de fonctionnalités "- pourquoi cela poserait-il problème?" Oui, bon point ... pourquoi les programmeurs utilisent-ils des choses inutiles comme les langages assembleur / C / de haut niveau alors que tout ce que vous pouvez en faire est déjà écrit langage machine directement? Le fait est que: fonctionnalités = augmentation de la vitesse de développement + facilité de maintenance accrue = réduction des coûts = meilleur L' utilisation shest identique à l'utilisation, à l' bashexception du fait qu'elle est plus lente, les programmes sont plus longs et plus difficiles à gérer.
Bakuriu
10
Ce n’est pas vraiment le manque de fonctionnalités, mais le fait que POSIX demande à la shcommande d’exécuter un shell compatible POSIX, ce que l’ancien shell Bourne n’est pas. Bien que POSIX n’exige pas shd’être présent /bin/sh, c’est le répertoire le plus logique.
Juillet
4
L'historique des commandes @ Bakuriu et l'édition en ligne de commande sont deux choses dont vous n'auriez pas vraiment besoin pour un script.
Strugee
4
@strugee Ce ne sont pas les seules différences. Par exemple sh, les extensions tilde et accolade ne sont pas développées, il manque des éléments intégrés (par exemple, pushdet popd, select) pas d’expansion arithmétique. Beaucoup de variables sont manquantes, par exemple PIPESTATUS.
Bakuriu
23

La déclaration dans votre question est incorrecte. Solaris jusqu'à la version 10 est la fourniture de l'héritage véritable shell Bourne /bin/sh. Ceci a été fait pour ne pas briser la compatibilité avec d'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 de versions similaires, y compris Solaris 11, fournissent un shell compatible /bin/shPOSIX car POSIX demande à la shcommande de lancer un shell POSIX, et non le shell Bourne hérité qui n'est pas conforme. /bin/shest généralement :

  • ksh88ou ksh93sur les implémentations commerciales Unix
  • un modifié bashsur OS/X(bien qu'il soit zsh)
  • un ashou pdkshdérivé sur autreBSDs
  • bashou dashsur les distributions Gnu / Linux.

Ce n'est pas nécessairement un lien, mais peut être un véritable exécutable sur de nombreux systèmes, mais sur GNU / Linux.

Fait intéressant, malgré ce que dit la réponse la plus élevée à votre question, ce n’est pas le manque de fonctionnalités qui incite les développeurs de la distribution à installer quelque chose de différent du shell Bourne hérité, /bin/shmais le désir d’être aussi conforme que possible à POSIX, c’est-à-dire Unix comme OS. Le fait que le shell POSIX ait plus de fonctionnalités que le shell Bourne existant n’est qu’un effet secondaire de cet objectif de conformité standard.

Il est également vrai que certains shells, notamment bash, se comportent différemment lorsqu'ils sont appelés sh, ce qui supprime principalement les fonctionnalités du shell, et non l'inverse.

jlliagre
la source
16

Autant que je sache, le shell Bourne original ne pouvait pas être utilisé par les BSD et le projet GNU, à cause de sa licence.

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

La même chose est vraie pour BSD4, le parent de tous les BSD. Grâce au procès intenté par AT & T, ils ont dû réécrire toutes les sources de l’Unix original, y compris le shell Bourne.

Dans la ligne BSD classique, le shell Bourne était expédié jusqu’à la version 4.3BSD-Reno (mais plus avec Net / 2 et les versions 4.4BSD suivantes). Pour des raisons de licence, il a ensuite été remplacé par Kenneth Almquist (souvent appelé cendre), du type shr4, compatible avec la technologie Bourne.

À partir de FreeBSD man sh

Une commande sh, le shell Thompson, est apparue dans la version 1 d'AT & T UNIX. Il a été remplacé dans la version 7 d'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 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.

Raphael Ahrens
la source
7

Il y a eu d'autres problèmes. Bourne Shell utilisait sbrk () à la place de malloc (), ce qui le rendait peu portable.

Après que Bourne Shell soit devenu OpenSource via OpenSolaris, j’ai créé une version portable hafway puis une version réellement portable en remplaçant sbrk () par malloc () avec l’aide de Geoff Collyer (la même personne qui avait évité sbrk () dans le Korn Shell).

La raison initiale pour laquelle j'ai créé une version portable du Bourne Shell est que j'ai aimé rendre l'éditeur d'histoire que j'ai écrit pour mon "bsh" entre 1982 et 1984 également disponible dans le Bourne Shell. Pendant ce temps, j'ai porté la plupart des caractéristiques uniques que j'ai écrites pour "bsh" sur Bourne Shell.

C'est entre autres:

  • Compile et fonctionne presque partout, y compris Cygwin (presque 2x plus vite que bash)
  • L'éditeur d'historique avec un tampon en anneau LRU
  • TERMCAP intégré
  • Alias ​​avancés (alias persistants globaux, alias locaux, ....) et, avec la fonction intégrée "dosh", Bourne Shell est la seule implémentation similaire à Bourne Shell qui autorise des alias paramétrables.
  • Prise en charge de la modification d'alias complexes dans l'éditeur d'historique en mode brut.
  • Accédez aux 32 bits du code exit (2) via des variables .sh. *.
  • chronométrage automatisé avancé avec une résolution de 6 chiffres
  • pushd / popd / dirs
  • construit "trouver"
  • Tuyau de stderr
  • Utiliser vfork () pour de meilleures performances.
  • Enfin, tous les bogues documentés de SVr4 Bourne Shell ont été corrigés. Par exemple, la suspension fonctionne toujours en mode de contrôle des tâches. ...

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

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

Je recommande 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

schily
la source
Salut Joerg. Pourquoi les porter dans le shell Bourne plutôt que dans un shell qui avait déjà été POSIXified comme un sh BSD ou un pdksh?
Stéphane Chazelas
Le portage de Bourne Shell était un défi car il n'utilisait pas la stdio. C'était un défi similaire à celui de prendre la source csh d'origine et de la compiler en remplaçant le printf non stdio écrit dans l'assembleur VAX. Mais j’ai déjà ajouté de nombreuses nouvelles fonctionnalités POSIX à Bourne Shell et j’aime rester avec Bourne Shell sous SchilliX afin de lui permettre de démarrer avec / anr / usr sur des systèmes de fichiers distincts, ce qui n’est pas possible avec Korn Shell.
Schily
Notez également que je voulais vérifier que la vitesse de ksh est causée par l'utilisation de vfork (). Maintenant que j'ai converti le shell Bourne pour utiliser vfork (), il est exactement aussi rapide que les versions récentes de ksh. C'est une expérience que vous n'obtenez que lors du démarrage avec le code source original de Bourne Shell.
Schily
D'accord, mais jusqu'à ce que vous rendiez ce sh conforme à POSIX, il ne risque pas de susciter beaucoup d'intérêt. Je me souviens que vous ayez posé des questions sur les incompatibilités avec POSIX du shell Bourne sur le groupe d’austin ML, c’est quelque chose sur lequel vous travaillez (ce qui signifierait une rupture de la compatibilité ascendante avec le shell Bourne)? De plus, les gens (au moins) considèrent la syntaxe POSIX sh comme un progrès par rapport au shell Bourne. Continuer à appeler votre shell dérivé de Bourne peut vous donner une mauvaise impression. Que diriez-vous de bimsh (Bourne amélioré (ala vi / vim))?
Stéphane Chazelas
Mon Bourne Shell est déjà meilleur que ksh à certains égards, par exemple implémenter de meilleurs alias, pushd / popd / dirs et un support pour l’usilisation des ressources basé sur les fonctionnalités UNIX modernes si ce que ksh fait est toujours basé sur SVr2. Comme vous semblez être intéressé et compétent dans le shell, je voudrais avoir des idées sur ce que vous voudriez voir ensuite dans Bourne Shell après avoir lu: schillix.sourceforge.net/man/man1/bosh.1.html Notez que jusqu'à présent, j'ai tout le nouveau code # ifdef'd et certaines fonctionnalités (comme les tubes stderr) doivent être activées via set (1).
Schily
4

Il est associé à des coques offrant une compatibilité ascendante à 100% . Vous ne perdez rien de ce que le shell original a, mais vous gagnez plus de fonctionnalités. Il n'y a pas d'inconvénients, alors pourquoi rater les nouvelles fonctionnalités? C'est la même raison pour laquelle /bin/viest généralement lié à vim .

JoelFan
la source
5
L'inconvénient est que les gens écrivent des scripts qui fonctionnent sur leur système, pensant que leur script est compatible lorsqu'il ne l'est pas. Une fois, j'ai corrigé près d'une centaine de scripts de shell Gentoo qui nécessitaient en réalité bash, mais appelés / bin / sh. Ils se sont tous cassés quand j'ai changé / bin / sh pour être dash au lieu de bash.
Zan Lynx
3
"pas d'inconvénient" - vitesse. par exemple bashest beaucoup, beaucoup plus lent quedash
strugee
@strugee Si vous recherchez des améliorations rapides dans un shell, vous n'utilisez probablement pas le bon outil pour ce travail.
Chris Down
1
@ChrisDown définir "améliorations de la plage ms"?
Strugee
2
La syntaxe POSIX sh n’est pas totalement compatible avec la syntaxe Bourne sh. Par exemple, IFS=,; rm file1,file2,file3supprimerait ces 3 fichiers dans le shell Bourne. Ce (idiot) fonctionnalité a été supprimée dans sh Posix. Il existe des dizaines de différences subtiles pouvant faire en sorte qu'un script écrit pour le shell Bourne fonctionne différemment avec un sh POSIX.
Stéphane Chazelas