Login
Newsletter
Werbung

Thema: Project Trident veröffentlicht erste stabile Version

20 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Sheller am Mo, 17. Februar 2020 um 17:01 #

"The default shell for Void Linux is “dash” and is the “/bin/sh” of the system.
It might be helpful to run chsh after logging in to change the default login shell, as dash is very limited.
In shell scripts, make sure to use “#!/bin/bash” instead of “#!/bin/sh”, otherwise you may experience odd script failures due to using “dash” instead of the traditional “Bourne shell”."

Warum wird dann überhaupt Dash als Standard verwendet, wenn man in Skripten doch wieder auf Bash wechseln soll?

  • 0
    Von Axel VOSS am Mo, 17. Februar 2020 um 19:08 #

    Ich erlaube mir auf folgenden Artikel zu verweisen, der dies erklärt.

    https://www.linux-magazin.de/ausgaben/2012/12/bash-bashing/

    • 0
      Von klopskind am Di, 18. Februar 2020 um 22:56 #

      Netter Artikel, danke.

      Ich sehe es ähnlich zum Fazit des Artikels. Allerdings kann ich das mit den "Race Conditions und Sicherheitslücken" ggü. dem vorherigen Zustand mit Bash nicht wirklich bewerten. Jedenfalls steige ich da nicht ganz dahinter.

      Insgesamt finde ich schon fragwürdig, wie viel eine dash netto tatsächlich bringt. Debian bzw. die erweiterte OSS-Community kann mit ihren Ressourcen nur eine gewissen Menge an Code warten und pflegen. Für ein einzelnes Software-Projekt oder Paket mag das ja alles funktionieren. Aber im erweiterten Sinne muss geht mit einer zusätzlichen Shell mehr und noch weiter divergierenden distributionsspezifischen Shell-Skripten die Rechnung jedenfalls in die negative Richtung.

      Die Vorteile einer dash spielen eigentlich nur auf wenigen Systemen wie etwa embedded ein Rolle. Dort gibt es auber auch busybox mit einer eigenen Shell (ash), die doch eigentlich gut genug ist (mksh ist noch sehr minimalistisch und wird meines Wissens nach unter Android verwendet). Unter diesen Systemen bedarf es zumeist allerdings auch einer schlankeren libc als der Implementierung von GNU. Da käme ein Debian also gar nicht mehr infrage. Deshalb kann die dash ihre Vorteile in Debian eigentlich gar nicht so gut ausspielen.

      • 0
        Von Verfluchtnochmal_5987108 am Mi, 19. Februar 2020 um 00:26 #

        Junge entweder dein Script ist posix konform oder ein bash Script, wenn die dash reicht ist es einfach um Welten effizienter und wenn nicht schreib den richtigen shebang oben hin

        Diverse Sicherheitslücken in den letzten Jahren die zB auch implizit alle shell commands des php interpreters betroffen haben waren mit einer anderen shell als /bin/sh kein Thema für den Fall irgend ein Trottel verwurstet da untrusted input

        • 0
          Von msi am Mi, 19. Februar 2020 um 20:41 #

          entweder dein Script ist posix konform oder ein bash Script

          Keinesfalls ist jedes Shellskript, das nicht POSIX-konform ist, ein Bash-Skript. Es könnte sich ebenso gut um ein Zsh-, *ksh-, *csh- oder rc-Skript handeln. Kommt halt darauf an, in welcher Sprache es geschrieben ist.

          • 0
            Von Verfluchtnochmal_5987108 am Do, 20. Februar 2020 um 22:12 #

            Und in keinem der Fälle schreibt jemand mit Hirn /bin/sh oben hin und schon ist das Thema default shell keines mehr

            Wirklich so schwer zu verstehen?

            • 0
              Von msi am Fr, 21. Februar 2020 um 14:45 #

              Und in keinem der Fälle schreibt jemand mit Hirn /bin/sh oben hin[.]

              Außer eben in Fällen, in denen nichts weiter vorausgesetzt werden kann als eine POSIX-kompatible Shell, die aber gleichzeitig vorausgesetzt werden muss. Dass man dann auch nur POSIX-kompatiblen Shellcode schreiben darf, erklärt sich von selbst.

              Wirklich so schwer zu verstehen?

              Mir war der Unterschied von POSIX sh und Bash etc. bereits klar, bevor der Artikel erschienen ist. Es ging mir, was sicherlich nicht allzu schwer zu verstehen ist, lediglich darum, dass die Behauptung, ein Shellskript sei „entweder [...] posix konform oder ein bash Script“, schlicht falsch ist.

          0
          Von klopskind am Mi, 19. Februar 2020 um 22:20 #

          Nicht in dem Ton, Freundchen! Wenn Sie Ihre Argumente in einer angemessenen und verständlichen Form äußern, würde ich erneut darüber nachdenken Ihnen inhaltlich zu entgegnen. So jedoch nicht!

        0
        Von kraileth am Mi, 19. Februar 2020 um 08:09 #

        Kleine Ergänzung aus meiner Erfahrung dazu: Das Unternehmen, für das ich arbeite, setzt auf seinen Servern sowohl diverse Pinguine als mitunter auch Teufelchen ein. Die meisten Kollegen haben einen reinen Linux-Hintergrund und haben sich so viel FreeBSD angeeignet, daß sie sich nicht verlaufen, wenn auf einem solchen System mal ein Problem auftritt, das sie lösen müssen. Allerdings versuchen sie, sich das System möglichst „linuxartig“ zu machen - mit diversen Aliasen, Symlinks und natürlich der gewohnten Shell.

        Als ich privat das Betriebssystem gewechselt habe, war ich auch versucht, einfach die bekannte Bash „mitzunehmen“, habe mich dann aber dagegenentschieden und für meinen Benutzer die tcsh gewählt (schlagendes Argument: Gehört im Gegensatz zu der Bash zum Basissystem). Obwohl ich inzwischen zur Zsh weitergezogen bin, habe ich die tcsh schätzen gelernt und kann damit gut leben.

        Wenn nun eine FreeBSD-Kiste mit extremer Load kämpft, weil z.B. ein Kunde einen Cronjob eingerichtet hat, der alle paar Minuten ein ziemlich ressourcenintensives Skript aufruft, das aber nicht überprüft, ob noch eine Instanz läuft (oder ähnliche solche Spielchen), muß man das ja wieder glattziehen. Die Standardshell habe ich nach dem SSH-Login selbst unter extremer Load praktisch sofort und bin (sobald sudo so nett ist und mir Rootrechte gibt) handlungsfähig. Die Kollegen, die erstmal die Bash aufrufen, sind ggf. erst Minuten (sic!) später am Start.

        Grundsätzlich stimme ich zu, daß es „unter normalen Umständen“ keinen großen Unterschied macht, welche Shell nun verwendet wird. Das Problem ist aber, daß diese „normalen Umstände“ nicht das sind, womit der Admin rechnen darf. ;)

        • 0
          Von msi am Mi, 19. Februar 2020 um 20:49 #

          Gegen die tcsh spricht allerdings, dass sie als csh-Abkömmling grundsätzlich nicht POSIX-kompatibel ist.

          Warum daran festgehalten wird, erschließt sich mir nicht. Mir scheint, FreeBSD macht es damit unnötig kompliziert. Bei OpenBSD ist einfach für alles ksh gesetzt, soweit ich mich erinnere. Damit kommt man, meiner Erfahrung nach, auch gut zurecht, wenn man bisher kaum was anderes als Bash benutzt hat.

          • 0
            Von klopskind am Mi, 19. Februar 2020 um 22:38 #

            Bei FreeBSD wird eben viel Wert auf Stabilität, Vertrautheit und POLA (policy of least astonishment) gesetzt. Veränderungen müssen gut begründet, durchdacht, getestet und ausgereift sein, bevor sie in FreeBSD landen. Ist ein wenig wie bei Slackware, dass mittlerweile dabei ist PAM in Slackware-current und somit auch in die vermutlich nicht mehr all zu fern liegende Veröffentlichung der Version 15 zu integrieren.

            Das hat große Vorteile, aber eben auch Nachteile. Letztlich ist es subjektiv, wie man diese für sich auslegt bzw. die Prioritäten setzt.
            Eine alternative Shell ist nur wenige Befehle auf der tcsh entfernt. :P

          0
          Von klopskind am Mi, 19. Februar 2020 um 22:32 #

          Ich denke, das dieses Phänomen einfach auf die Tatsache der Verbreitung und der Bekanntheit zurückzuführen ist. Selbst Apple ist von der tcsh als Teil der Überschneidungen mit FreeBSD dann doch auf die Bash gewechselt, solange diese noch unter GPL2 lizensiert gewesen. Die alte GPL2-Version der Bash wurde noch eine Weile mitgeschleppt bis aus lizenztechnischen Gründen irgendwann die zsh Einzug hielt.

          Zu der Sache in Ihrem dritten Absatz kann ich leider nichts beitragen. Ich würde meinen, dass die Bash schon um einiges fetter ist als eine tcsh. Könnte es eventuell daran liegen, dass die tcsh aus irgendwelchen Gründen im Gegensatz zur Bash noch im Cache lag (System-Skripte / Cronjobs etc.)? Ansonsten habe ich dieses Verhalten unter großer Last schon ab und zu unter Linux erleben müssen. Im Jahr 2020 eigentlich technisch unnötig soetwas. Das geht auch gescheiter, wenn man die richtigen Designentscheidungen und Standardeinstellung durchsetzen würde.

          Wie gesagt, ich denke, dass es auf den heutigen Kisten (Server und Desktops/Laptops) von der Stange aus Sicht der Hardwareressourcen keinen nennenswerten Unterschied mehr macht. Da sind andere Ressourcen wie bestehnde Kenntnis, verbreites Wissen, gute Doku und die Verbreitung einfach ausschlaggebender. Hinzu kommt aus Sicht der OSS-Projekte und -Communities, dass netto weniger Code gewartet werden muss, wenn man neben der Bash keine weitere Shell zu pflegen hat.

    1
    Von Verfluchtnochmal_5987108 am Di, 18. Februar 2020 um 00:00 #

    Weil /bin/ah nun mal eine posix compatible shell impliziert und wenn du mit dem shebang bashisms benutzt einfach ein Depp bist

    Den shebang gibt es nicht aus Spass, viele Deppen kopieren sich das /bin/sh leider ohne Verstand wo zusammen und schreiben dann bash scripts drunter

    • 0
      Von Sheller am Di, 18. Februar 2020 um 10:26 #

      Und warum gehen die davon aus, dass ich Bash-Skripte habe? Die Empfehlung klingt eher so, als wäre Dash nicht POSIX konform.

      P.S.: Deinen Tonfall kannst du dir sonstwo hin stecken.

      • 0
        Von Verfluchtnochmal_5987108 am Mi, 19. Februar 2020 um 00:20 #

        Weil du sonst keinen Grund für den Kommentar hättest? Mach dich mal schlau wo dash den Ursprung hat Herrgottnochmal

    0
    Von Pupstoffel am Di, 18. Februar 2020 um 12:45 #

    It might be helpful to run chsh after logging in to change the default login shell, as dash is very limited.

    Ist nicht die Begründung direkt in deinem Zitat?
    LG

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung