Login
Newsletter
Werbung

Thema: Bash 5.0 nähert sich der Fertigstellung

12 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
mehr 5.0
1
Von Fertig am Di, 8. Januar 2019 um 12:17 #

Wieso Veröffentlichungskandidat? Das IST die 5.0. (final, gold, RTM oder wie man es nennen mag).

  • 1
    Von Polynomial-C am Di, 8. Januar 2019 um 15:49 #

    Um das mal deutlich zu machen; Chet Ramey hat gestern die finale Version von bash-5.0 freigegeben:

    http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063.html

    1
    Von cyberpatrol am Mi, 9. Januar 2019 um 23:33 #

    Das IST der Veröffentlichungskandidat!

    Bash 5.0 RC1
    RC = Release Candidate (auf Deutsch: Veröffentlichungskandidat)

    Das ist die Version, die zur finalen, stabilen Version wird, wenn innerhalb einer gewissen Zeit keine wesentlichen Fehler mehr auftreten und sie so läuft, wie sie laufen soll.

    Und wenn du mal mit der Maus über den Link fährst, siehst du, dass in der URL sogar noch explitzit "testing" drin steht. Was das bedeutet, muss ich dir jetzt hoffentlich nicht erklären.

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Jan 2019 um 23:34.
0
Von schmidicom am Di, 8. Januar 2019 um 13:23 #

Wie es aussieht haben sie auch ihr build system mal überarbeitet...
Einigen Aussagen zufolge soll das beim genaueren hinsehen ja regelrecht zum fürchten gewesen sein. ;)

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 08. Jan 2019 um 13:24.
1
Von Ghul am Di, 8. Januar 2019 um 20:47 #

Mich würde mal interessieren, welche Shell für das Programmieren am ausdrucksstärksten und konsistentesten ist?


Neulich habe ich bspw. ein Shellskript mit typischen Programmierkonstrukten wie diverse Variationen der for Schleife geschrieben, allerdings stoß ich dann irgendwann auf irgendein Problem.
In einem Fall hat eine foreach typisches Konstrukt bestens funktioniert, leicht abgewandelt funktionierte es dann plötzlich nicht mehr obwohl es eigentlich müsste, am Schleifenkörper änderte ich nämlich kaum etwas. Es ist im Nachhinein leider schwer zu erklären, da ich das Skript nur kurz benötigte und dann löschte.
Ich musste die foreach Schleife jedenfalls in eine klassische for Schleife umbauen, damit sie funktionierte.

Die verwendete Shell war die Bash.
Irgendwie war das, was eigentlich funktionieren hätte müssen und dann doch nicht funktionierte, inkonsistent.
Das war irgendwie wie früher das Programmieren in einer alten PHP Version.

Auch war die Ausdrucksstärke unter Verwendung von Variablen eher schwach, verglichen mit einer richtigen Programmiersprache.

Insofern würde mich mal interessieren, welche Shells hier besser sind?
Innere Konsistenz und Ausdrucksstärke wären für mich schon zwei wichtige Features, die eine Skriptsprache und die Sprachfeatures einer Shell haben sollte.

  • 1
    Von hjb am Di, 8. Januar 2019 um 23:18 #

    Die zsh hat deutlich mehr Funktionen als die Bash, die schon eine nicht gerade kleine Manpage hat. Beispielsweise sehr mächtige Array- und Hash-Funktionen und Erweiterungsmodule. Dabei ist sie meines Wissens sogar kleiner als die Bash. Ich habe allerdings nur die Größe des Binarys betrachtet, keine Messungen von RAM-Bedarf oder Geschwindigkeit zur Laufzeit.

    Es ist aber nicht zu empfehlen, eine Shell für größere Programme zu verwenden, selbst wenn man im Prinzip mit Shellcode alles programmieren kann. Denn die Möglichkeiten, Fehler zu machen, sind grenzenlos und die Handhabung von Sonder- und Escape-Zeichen kann sehr schwierig werden. Bei der Bash führt schon ein fehlendes Leerzeichen vor der rechten Klammer in einem Ausdruck wie

    if [ condition ]

    dazu, dass das Resultat falsch ist, ohne dass man eine Fehlermeldung erhält.

    • 1
      Von glasen am Mi, 9. Januar 2019 um 08:43 #

      Auch ein toller Fehler in Shell-Skripten ist es bei der Definition von Variablen Leerzeichen einzubauen:

      a = "Hello World"

      Jede andere "Programmiersprache kann damit umgehen, nur eben die Bash nicht. Aus dem Grund schreibe ich komplexere Skripte nur noch in Python. Das lässt sich besser debuggen und bietet auch eine viel mächtigere Syntax.

      1
      Von msi am Mi, 9. Januar 2019 um 22:31 #

      Dabei ist sie [Zsh, msi] meines Wissens sogar kleiner als die Bash.

      Zunächst sieht das so aus, ja:

      $ ls -lh | grep '\.tar$'
      -rw-r--r-- 1 msi msi 31M Jan 9 21:37 bash-5.0.tar
      -rw-r--r-- 1 msi msi 17M Jan 9 21:39 zsh-5.6.2.tar

      Aber dann stellt sich raus:

      $ tar xf bash-5.0.tar
      $ ls
      bash-5.0/ bash-5.0.tar zsh-5.6.2.tar
      $ cd bash-5.0
      $ du -h po/
      13M po/

      Im Verzeichnis po befinden sich die zahlreichen Übersetzungen der Nachrichten, die Bash ausgibt, in andere Sprachen, von af für Afrikaans bis zh für Chinesisch. Zsh hingegen gibt's bisher nur auf Englisch.

      0
      Von msi am Do, 10. Januar 2019 um 19:21 #

      Na gut, das war zunächst nur ein Vergleich der Größe der Quellarchive. Du meintest ja, du hattest die Größe der Binärdateien verglichen, womit wahrscheinlich ein Vergleich der Dateien /bin/bash und /bin/zsh gemeint ist.

      Der ergibt auf meinem System (Devuan ASCII, x86_64):
      1,3M /bin/bash
      840K /bin/zsh

      Nun besteht aber eine Bash- oder Zsh-Installation aus mehr als nur dieser einen Datei. Zu vergleichen wäre also eher das, was insgesamt rauskommt, wenn man die Quelldateien mal übersetzt. Da schlägt Bash dann bei mir mit 17MB zu Buche, Zsh mit lediglich 7,3MB. Also, das ist jeweils die Gesamtgröße aller beim Ausführen von make generierten Dateien in einem von den Quelldateien gesonderten Verzeichnis.

      Die Größe dessen, was dann wirklich installiert wird, ist für Bash noch etwas geringer. Bei mir sind es 13MB. Zsh konnte ich leider nicht testen, weil make install mit einem Fehler abbricht.

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Jan 2019 um 20:38.
Pro-Linux
Frohe Ostern
Neue Nachrichten
Werbung