Programmieren: bash oder was anderes? -- Grundsatzdiskussion

[unitra]

Abgespalten von viewtopic.php?f=28&t=178652


Also programieren mit der bash, mach das nicht, Du wirst Dich ärgern im Nachhinein.

Wähle entweder Python oder Perl, oder schreibe gleich eine Applikation in C. Aber mit der BASH programmieren, lass das sein. Für ein kleines Skript zwischendurch (15 Zeilen maximal) ist bash in Ordnung. Für umfangreiche Programmierung, nicht das richtige Werkzeug.

Hallo,

ich möchte Verzeichnisse durchsuchen, Text- oder json-Dateien, oder Verzeichnisnamen, auslesen. Entsprechend eine Datenbank anlegen, befüllen, aktualiiseren. Evtl. auch danach Musikdateien taggen - wohl eher nicht direkt, sondern per Programmaufruf, also ggf. zusätzliche Software. Es können z.B. 4.000 Verzeichnisse, ggf. Unterverzeichnisse, und z.B. 30.000 Einträge sein. Per Shell-Skript wird es wohl schon vor der Datenbank bei komplexeren Arrays schwierig?

LG

[whisper]

Also programieren mit der bash, mach das nicht, Du wirst Dich ärgern im Nachhinein.

Wähle entweder Python oder Perl, oder schreibe gleich eine Applikation in C. Aber mit der BASH programmieren, lass das sein. Für ein kleines Skript zwischendurch (15 Zeilen maximal) ist bash in Ordnung. Für umfangreiche Programmierung, nicht das richtige Werkzeug.

Kann ich nur zustimmen, Ich habe vor einiger Zeit ein Bash Script geschrieben (schreiben müssen, weil keine andere Sprache zur Verfügung stand)
Es hat ca. 6000 Zeilen, das ist definitiv nur schwer wartbar. Und ich habe selber Respekt davor, noch Änderungen einzupflegen

Python wär da besser gewesen, selbst wenn ich da eine Anfängerphase mit einrechne.

[heisenberg]

Warum man für Programme (ab einer gewissen Größe(z. B. 50-100 Zeilen) nicht bash verwenden sollte:

https://superuser.com/a/936296 (englisch)

[willy4711]

Ich will nochmal auf den ursprünglichen Titel des Threads zurückgreifen, da ich es sinnvoll fände, dies nicht abstrakt zu lösen:

Programmieren: Metadaten auslesen, Musik taggen -- bash oder was anderes?

Das Problem, das offensichtlich besteht:

Und: fb2k läuft bei mir z.B. mit separaten tags, wenn ein Linuxprogramm das nicht unterstützt müßte ich zig tausende Files konvertieren oder gar händisch taggen. Bei meiner Suche habe ich auch da nichts gefunden, m-tags.org ist gerade nicht erreichbar sonst könnte ich nochmal schauen. Vgl. http://www.foobar2000.org/components/view/foo_tags Und keiner kann mir erklären, warum es so schrecklich ist, das in vielen Punkten alternativlose fb2k mit wine zu nutzen - ist da etwa schon Impfstoff von Gates enthalten oder was?

Ich kenne ja nun nicht die Programmierkenntnisse von curt123. Aber gefühlsmäßig würde ich sagen, das das ein ziemlich umfangreiches Unterfangen wird. Und das alles, um die Metadaten seiner Musikdateien mit externen Tags weiter zu pflegen,
die eh kein Linux-Programm und auch unter Windows nur Foobar lesen kann?

Wenns denn Spaß macht....

Ich habe mich etwas mit der m-TAGS Methode belesen, Metadaten zu speichern.
https://hydrogenaud.io/index.php/topic,97164.0.html sagt:

Version 1.0 now available. Main upgrades are:

1) you can now write the tags from an m-TAGS file back to the media files;

Wäre das nicht die einfachere Methode?

Mehr will und kann ich nicht sagen, da das Wissen, so was zu programmieren mir fern ist.

[curt123]

Grundsätzlich kann ich die Argumentation in Richtung Komplexität oder Scriptlänge so pauschal nur bedingt nachvollziehen, wenn es offenbar Möglichkeiten gibt, Funktionen usw. auszulagern bzw. externe Dateien aufzurufen oder quasi includes zu realisieren, etwa per source.

[dollo]

https://xkcd.com/353/

[heinz]

Hallo Zusammen,

ich finde es "schrecklich" wie hier die Programmierung in bash oder allgemein als Script "schlecht geredet" wird.

Es hat wohl eher damit zu tun wie gut jemand die entsprechende Sprache/"Art zu Coden" kennt und damit zurecht kommt.

Meine wenigkeit kat schon viele Scripte geschrieben, die mehrere tausend Zeilen an Code enthalten.
Sie funktionieren seit langer Zeit sehr gut, sind super "Wartbar" und ich habe sie schon oft erweitert oder veraendert ohne groessere Probleme dabei zu haben als mit anderen Sprachen.

Scripte sind Hochflexiebel und auf jede Situation anpassbar.
Der einzige Nachteil ist manchmal die Geschwindigkeit.
Wenn es stark auf Geschwindigkeit ankommt nutze ich C, aber so gut wie alle Probleme lassen sich auch sehr gut als Shellscript loesen.

Das Hauptproblem an Scripten ist oft, dass wenn der Code an andere weitergegeben wird, diese nicht genau nachvollziehen koennen was sich der Ersteller dabei gedacht hat.
Es ist sehr vom Kenntnisstand der Coders/Lesers abhaengig.
Das mag auf Scripte mehr zutreffen als auf andere Sprachen aber das liegt m.M.n. an der riesigen flexibilitaet, die einem die Shell bietet.

Wenn man ein Programm fuer einen bestimmten Zweck und nur fuer sich selbst erstellt, sollte man meiner Meinung nach die Sprache verwenden in der man sich am "wohlster/sichersten" fuehlt.

Ich moechte hier nicht sagen, dass Shell und bash das absolute Top ist aber die negativen Kommentare die ich hier lesen musste hat diese Art der Programmerstellung wirklich nicht verdient.

Gruss,
heinz

[JTH]

Ich schließe mich deinem Beitrag an, Heinz.

Wahrscheinlich gab es zu Anfangszeiten der Unix-Shells mehr Fälle, in denen man zur Aufgabenlösung zu eben jenen gegriffen hat – da gibt es heute einfach mehr Sprachen, die sich für bestimmtes anbieten. Aber wie immer in der Entwicklung sollte das abhängig von der Aufgabe sein, das passende Werkzeug – die passende Sprache – für die bestehende Aufgabe. Und da haben Shells und ihre Sprachen durchaus ihre Stärken, wenn man z.B. viele andere Anwendungen aufrufen muss und deren Ein- & Ausgaben umleitet und weiterverarbeitet. Größere mathematische Aufgaben würde man natürlich nicht damit lösen.

Es lassen sich durchaus auch größere Aufgaben als 100-Zeilen-Skripte lösen. Ein 6000-Zeilen-Skript kann natürlich unübersichtlich sein. Aber auch da gibt es Wege durch Aufteilen in Funktionen, mehrere Dateien, etc. – Modularisierung. Wie man sie in anderen Sprachen bei größeren Projekten auch betreibt. Ob es übersichtlich ist, ist – meiner Erfahrung nach – oft eher eine Frage des Stils und auch der eigenen Erfahrung, nicht der Sprache an sich. Auch ein Python-Projekt kann unintuitiv geschrieben sein.

Um Fallstricke zu vermeiden kann man – wie wiederum bei anderen Sprachen auch – Werkzeuge benutzen. Für Bash/Sh finde ich shellcheck ziemlich hilfreich. Oder man benutzt den sogenannten „Bash Strict Mode“ (über den Sinn aller empfohlenen Optionen kann man diskutieren).

[heinz]

Ich schließe mich deinem Beitrag an, Heinz.

Danke dafuer, dass ich nicht alleine bin...

– da gibt es heute einfach mehr Sprachen, die sich für bestimmtes anbieten.

Das ist sicher korrekt.
Wenn ich aber bereits eine gut funktionierende Loesung fuer ein Problem habe, warum sollte ich dann auf eine andere Sprache wechseln?
Weil sie es ein paar millisekunden schneller macht oder der Code fuer manche Leute einfacher verstaendlich ist?

Klar, wenn ich von null beginne und eine Computersprache erlernen will ist es sicher sehr sinnvoll sich nach dem zu richten, was man braucht, in Zukunft benoetigen wird (Ist nicht einfach...) und was man auch versteht.

Die Logik von Shellscripten erschliesst sich vielen nicht so einfach, weil man auf
sehr viele Programme zugreifen kann, die oft unterschiedliche Optionen und Ausgaben haben.

Größere mathematische Aufgaben würde man natürlich nicht damit lösen.

Wenn es nicht auf Geschwindigkeit ankommt, warum nicht?
bc ist ein super mathematisches Tool, welches man aus scripten hervorragend nutzen kann.

Für Bash/Sh finde ich Debianshellcheck ziemlich hilfreich.

Da stimme ist Dir ebenfalls zu. (>bash -x< kann auch sehr hilfreich sein...)
Allerdings, ich bin garantiert nicht der "Supercoder", habe ich solche Tools nie benoetigt.
Ein einfaches "echo $variable;read" oder "set|less" an entscheidenden Stellen hat bisher all meine "Probleme" geloest.
Das ist m.M.n. ja gerade die Staerke am scripten.
Es ist wie das Basteln mit Knetgummie. Wenn wo was fehlt, "klebt" mann es einfach an...
(Ist sicher nicht jedermanns geschmack/stiel... )

M.M.n. wird die shell in der heutigen Zeit sehr unterschaetzt.
Eines meiner Scripte erstellt z.B. Animationen aus Bildern, die echt nicht schlecht aussehen (mittels convert).
Es enthaelt einen eigenen Parser und damit eine eigene Sprache um aus verschiedenen Bildern automatisiert eine Animation zu erstellen.
Es wurde mehrfach erweitert und geaendert (durch mich...). Es laeuft und laeufet und lauft ........
(ca. 6000 Zeilen...)

Die Komplexitaet eines Projektes ist nicht das Problem der "Computersprache" welche ich verwende, sondern der Art meines verstaendnisses der Aufgabe die ich erledigt haben moechte.

Und fuer mich zaehlt am Ende das Ergebnis.
Wenn das Programm tut was ich moechte, bei allen falscheingaben die mir einfallen, ist das Programm Top.

Gruss,
heinz

[Meillo]

Es lassen sich durchaus auch größere Aufgaben als 100-Zeilen-Skripte lösen. Ein 6000-Zeilen-Skript kann natürlich unübersichtlich sein. Aber auch da gibt es Wege durch Aufteilen in Funktionen, mehrere Dateien, etc. – Modularisierung. Wie man sie in anderen Sprachen bei größeren Projekten auch betreibt. Ob es übersichtlich ist, ist – meiner Erfahrung nach – oft eher eine Frage des Stils und auch der eigenen Erfahrung, nicht der Sprache an sich. Auch ein Python-Projekt kann unintuitiv geschrieben sein.

Das finde ich einen wichtigen Punkt. So wie man in Python keine Klasse mit 6000 Zeilen schrieben wuerde, so wuerde man auch in der Shell kein Script mit 6000 Zeilen schreiben. Wenn man in Python eine weiter Klasse anlegt, so legt man in der Shell halt ein weiteres Script an. Die Modularisierung passiert da halt eine Ebene hoeher. Es ist egal in welcher Sprache man programmiert, man sollte immer Probleme zerlegen und den Code modularisieren, wie genau man das technisch umsetzt unterscheidet sich je nach Programmiersprache.


Ich finde, dass es etliche Gruende gegen Shellscripte gibt, ebenso wie es etliche dafuer gibt. Es haengt vom jeweiligen Projekt ab, welche fuer mich wichtiger zaehlen. Pauschal laesst sich das IMO nicht sagen.

[heisenberg]

ich finde es "schrecklich" wie hier die Programmierung in bash oder allgemein als Script "schlecht geredet" wird.
Es hat wohl eher damit zu tun wie gut jemand die entsprechende Sprache/"Art zu Coden" kennt und damit zurecht kommt.

Was mich betrifft, der von mir gepostete Link(https://superuser.com/a/936296) fasst so einiges zusammen, was ich selbst erfahren habe, was mir nicht gefallen hat. Ich frage mich, ob das überhaupt jemand gelesen hat.

Ich selbst haben in meinem Leben bestimmt schon einige 100K Zeilen mit bash geschrieben. Letztlich ist dies nur meine eigene Erfahrung/Meinung und es ist absolut in Ordnung, wenn andere Menschen das anders sehen. Ich selbst habe es hier und da bereut, meine Zeit und Energie in Skripte zu stecken, die für mich im Nachhinein in einer anderen Sprache besser investiert gewesen wäre.

Hier mal ein nicht all zu grosses Beispiel in bash, was ich auf jeden Fall nicht wieder mit bash lösen wollen würde, wenn ich es erneut anginge:

https://codeberg.org/megabert/script-pa ... dns-manage

Es lassen sich durchaus auch größere Aufgaben als 100-Zeilen-Skripte lösen. Ein 6000-Zeilen-Skript kann natürlich unübersichtlich sein. Aber auch da gibt es Wege durch Aufteilen in Funktionen, mehrere Dateien, etc. – Modularisierung. Wie man sie in anderen Sprachen bei größeren Projekten auch betreibt. Ob es übersichtlich ist, ist – meiner Erfahrung nach – oft eher eine Frage des Stils und auch der eigenen Erfahrung, nicht der Sprache an sich. Auch ein Python-Projekt kann unintuitiv geschrieben sein.

Das finde ich einen wichtigen Punkt. So wie man in Python keine Klasse mit 6000 Zeilen schrieben wuerde, so wuerde man auch in der Shell kein Script mit 6000 Zeilen schreiben. Wenn man in Python eine weiter Klasse anlegt, so legt man in der Shell halt ein weiteres Script an. Die Modularisierung passiert da halt eine Ebene hoeher. Es ist egal in welcher Sprache man programmiert, man sollte immer Probleme zerlegen und den Code modularisieren, wie genau man das technisch umsetzt unterscheidet sich je nach Programmiersprache.

Das ist gerade der Punkt für mich. Wenn ich in der Bash in Richtung professioneller Programmierung gehe(Modularisierung, Kapselung), dann zeigt sich für mich gerade die Anfälligkeit bzw. Sensibilität und Mängel in einigen Bereichen(Quoting, Rekursives Quoting, umständliche Datenübergabe an Funktionen und auch die Rückgabe, ...) sowie mangelnder Komfort und Robustheit.

Meine Erfahrung ist, dass ich mit bash bis zu einer gewissen Größe - wenn ich Abstriche an die Programmiersauberkeit bereit bin in Kauf zu nehmen - sehr schnell in der Umsetzung bin. Aber ist diese Größe erreicht, dann kippt das ganz schnell zu Gunsten einer richtigen Scriptsprache. Welche Größe daß so genau ist, dass ist auch immer eine Einzelfallentscheidung, die auch berücksichtigt, dass Scripte üblicherweise deutlich länger werden, als ich sie anfangs einschätze. (50-100 Zeilen mögen da vielleicht etwas übertrieben kurz sein.)

Wenn man über bash und Geschwindigkeit spricht, dann heisst dass nicht, dass bash selbst langsam oder ineffizient ist. Es ist einfach das zu Grunde liegende Konzept, fast alles als separaten Prozess zu auszuführen. Mit achtsamer Programmierung(verwendung interner Bash-Funktionen) kann man viele Prozesserzeugungen vermeiden. Auch kann es sein, wenn es um die tatsächliche Verarbeitungsgeschwindigkeit geht, dass Bash in Kombination mit fgrep/awk/sed auch deutlich schneller ist als etwas in Python/Ruby/..., weil gerade z. B. in Ruby die sehr bequemen Konstrukte sehr schnell ineffizient beim Verarbeiten großer Datenmengen sein können im Vergleich zum zeilenorientierten Ansatz von awk, sed. (Kann man in Ruby,.. natürlich ähnlich machen, ist dann halt nicht mehr ganz so elegant).

[Meillo]

Das ist gerade der Punkt für mich. Wenn ich in der Bash in Richtung professioneller Programmierung gehe(Modularisierung, Kapselung), dann zeigt sich für mich gerade die Anfälligkeit bzw. Sensibilität und Mängel in einigen Bereichen(Quoting, Rekursives Quoting, umständliche Datenübergabe an Funktionen und auch die Rückgabe, ...) sowie mangelnder Komfort und Robustheit.

Meine Erfahrung ist, dass ich mit bash bis zu einer gewissen Größe - wenn ich Abstriche an die Programmiersauberkeit bereit bin in Kauf zu nehmen - sehr schnell in der Umsetzung bin. Aber ist diese Größe erreicht, dann kippt das ganz schnell zu Gunsten einer richtigen Scriptsprache. Welche Größe daß so genau ist, dass ist auch immer eine Einzelfallentscheidung, die auch berücksichtigt, dass Scripte üblicherweise deutlich länger werden, als ich sie anfangs einschätze. (50-100 Zeilen mögen da vielleicht etwas übertrieben kurz sein.)

Ich vermute, dass das alle so sehen werden. Im Kleinen ist die Shell oft der einfachste und direkteste Weg Ergebnisse zu bekommen. Je groesser, ansprungsvoller, sicherheitskritischer das Programm wird, desto eher verlagert sich der Kompromiss von der Shell zu ``richtigen'' Programmiersprachen. Das ist aber weder ein Argument gegen die Shell noch eines fuer die Scriptsprachen. Beides hat sein Einsatzgebiet, in dem es die beste Option ist. Mit der Shell grosse Projekte anzugehen ist ebenso unguenstig wie mit maechtigeren Programmiersprachen kleine Helferlein.

Ich persoenlich habe kein grosses Problem damit, ein Script, das mit der Zeit gewachsen ist, irgendwann mal in einer inzwischen besser geeigneten Sprache neu zu implementieren (oder auch anders rum, was aber seltener vorkommt). Bei wenigen Hundert Codezeilen ist der Aufwand zumeist ueberschaubar. Auf mehrere Tausend Codezeilen waechst es bei mir selten ohne dass ich das zuvor schon absehen konnte.

[Tintom]

Hier mal ein nicht all zu grosses Beispiel in bash, was ich auf jeden Fall nicht wieder mit bash lösen wollen würde, wenn ich es erneut anginge:

https://github.com/megabert/script-past ... dns-manage

Warum? Was hat dich daran gestört? Ich finde es zumindest übersichtlicher als manche Skripte, die es in ein offizielles Paket schaffen.

[heisenberg]

Ich vermute, dass das alle so sehen werden. Im Kleinen ist die Shell oft der einfachste und direkteste Weg Ergebnisse zu bekommen. Je groesser, ansprungsvoller, sicherheitskritischer das Programm wird, desto eher verlagert sich der Kompromiss von der Shell zu ``richtigen'' Programmiersprachen. Das ist aber weder ein Argument gegen die Shell noch eines fuer die Scriptsprachen.

Von der Tendenz her mit Sicherheit. Aber von den eigenen Schwellwerten, ab wann der Umstieg vernünftig ist, bestehen da wohl erheblich unterschiedliche Meinungen.

Warum? Was hat dich daran gestört?

Besonders nervig fand ich das Quoting und Doppelquoting, was ich total unübersichtlich finde und wo immer wieder Fehler aufgetreten sind, weil ich es doch nicht korrekt umgesetzt hatte. Es ist auch immer schwierig zu lesen. Auch kann man aus Leserlichkeitsgründen nicht einfach mal ein paar Zeilenumbrüche reinsetzen, ohne dass die
in den Variabeninhalten landen.

Auch so etwas nervt mich sehr:

Code: Alles auswählen

	if [ -n "$data" ] ; then
		info "REQUEST: curl --silent -w "%{http_code}" -X $method -H "X-API-Key: ***" --data "$data" $pdns_api_base$uri"
		curl --silent -w "%{http_code}" -X $method -H "X-API-Key: $pdns_api_secret" --data "$data" $pdns_api_base$uri >$tmpfile
	else
		info "REQUEST: curl --silent -w "%{http_code}" -X $method -H "X-API-Key: ***"  $pdns_api_base$uri"
		curl --silent -w "%{http_code}" -X $method -H "X-API-Key: $pdns_api_secret" $pdns_api_base$uri >$tmpfile
	fi

Warum muss ich etwas 4 x explizit schreiben, obwohl eigentlich 1 x reichen sollte? Ich kann den Befehl nicht in eine Variable schreiben, weil dann die Feldtrennung dann nicht mehr korrekt ausgeführt wird. Ich kann da auch nicht einfach ein template(printf) verwenden, sondern muss es auch wirklich 4 x ausschreiben. (Geht das evtl. besser?)

So würde ich das ungefähr erwarten(Beispielsyntax für Ruby):

Code: Alles auswählen

cmd = "curl --silent -w "%{http_code}" -X $method -H "X-API-Key: ***" #{$data?"--data \"$data\"":""} $pdns_api_base$uri"
dbg cmd
system cmd

Die anderen Punkte aus dem Link sind natürlich grundsätzlich da.

[Meillo]

Auch so etwas nervt mich sehr:

Code: Alles auswählen

	if [ -n "$data" ] ; then
		info "REQUEST: curl --silent -w "%{http_code}" -X $method -H "X-API-Key: ***" --data "$data" $pdns_api_base$uri"
		curl --silent -w "%{http_code}" -X $method -H "X-API-Key: $pdns_api_secret" --data "$data" $pdns_api_base$uri >$tmpfile
	else
		info "REQUEST: curl --silent -w "%{http_code}" -X $method -H "X-API-Key: ***"  $pdns_api_base$uri"
		curl --silent -w "%{http_code}" -X $method -H "X-API-Key: $pdns_api_secret" $pdns_api_base$uri >$tmpfile
	fi

Warum muss ich etwas 4 x explizit schreiben, obwohl eigentlich 1 x reichen sollte? Ich kann den Befehl nicht in eine Variable schreiben, weil dann die Feldtrennung dann nicht mehr korrekt ausgeführt wird. Ich kann da auch nicht einfach ein template(printf) verwenden, sondern muss es auch wirklich 4 x ausschreiben. (Geht das evtl. besser?)

So würde ich das ungefähr erwarten(Beispielsyntax für Ruby):

Code: Alles auswählen

cmd = "curl --silent -w "%{http_code}" -X $method -H "X-API-Key: ***" #{$data?"--data \"$data\"":""} $pdns_api_base$uri"
dbg cmd
system cmd

So sollte sich das (POSIX-kompatibel) loesen lassen:

Code: Alles auswählen

info "REQUEST: curl --silent -w "%{http_code}" -X $method -H "X-API-Key: ***"  $pdns_api_base$uri"
		curl --silent -w "%{http_code}" -X $method -H "X-API-Key: $pdns_api_secret" ${data:+--data "$data"} $pdns_api_base$uri >$tmpfile

Siehe:

${name:+word}
If name is set and not NULL, word is substituted;
otherwise, nothing is substituted.

[Lord_Carlos]

Hallo Zusammen,
ich finde es "schrecklich" wie hier die Programmierung in bash oder allgemein als Script "schlecht geredet" wird.
Es hat wohl eher damit zu tun wie gut jemand die entsprechende Sprache/"Art zu Coden" kennt und damit zurecht kommt.

Ich moechte hier nicht sagen, dass Shell und bash das absolute Top ist aber die negativen Kommentare die ich hier lesen musste hat diese Art der Programmerstellung wirklich nicht verdient.

Ich habe die Kommentare gar nicht so negativ aufgefasst.
Und es wurde mehrmals die Skriptsprache Python empfohlen wenn er von neu anfaengt, aber auch gesagt er soll das verwenden was am besten zu ihm passt.
______________________________________

Gibt es eine IDE die Automatischevervollstaendigung, Umbennen und Syntax check hat?
Geht das ueberhaupt? Das muesste dann ja auch alle Bash Kommandos und ihre Parameter kennen.

[MSfree]

Ein wesentlicher Nachteil von bash-Skripten ist, daß sie keine lokalen Variablen unterstützen, und daß es keine Typsicherheit gibt.

Variablen sind immer global und alles ist ein String. Strukturierte Programmierung ist dadurch erheblich erschwert bis fast unmöglich. Solange die Projekte klein und vom Umfang übersichtlich sind, kann man diese Nachteile hinnehmen. Eine Obegrenze von 100 Zeilen finde ich dann doch ein wenig niedrig angesetzt, man sollte hier also ein wenig mit Bauchgefühl entscheiden.

Skripte werden (zumindest von mir) eingesetzt, um den Aufruf anderer Programme zu vereinfachen. Wenn ich mir z.B. ansehe, wie lang ein Aufruf von rsync werden kann, dann kann ein Skript, in dem der ganze lange Aufruf eingetragen wird, durchaus hilfreich sein, auch wenn der länger als 200 Zeilen wird.

Ablaufgesteuerte "Programme" sollte man aber ab einer gewissen Komplexität lieber in einer "richtigen" Programmiersparche schreiben. Aber auch hier gilt, eine feste Obergrenze z.B. an if/do/for-Statements kann man eigentlich nicht geben. Aber spätestens, wenn ein Aussenstehnder ein Shellskript nicht innerhalb einer Stunde durch lesen komplett nachvollzogen und verstanden hat, dann ist es definitiv zu umfangreich.

[tobo]

Ein wesentlicher Nachteil von bash-Skripten ist, daß sie keine lokalen Variablen unterstützen[...]

Schon mal sowas

Code: Alles auswählen

f(){
    local i=42
    echo $i
}

i=0
echo $i
f
echo $i

ausgeführt in z.B. bash, dash, mksh?

[curt123]

Und es wurde mehrmals die Skriptsprache Python empfohlen wenn er von neu anfaengt, aber auch gesagt er soll das verwenden was am besten zu ihm passt.

Es gibt im konkreten Fall als Sollanforderung idelaierweise das Vorhandensein einer geeigneten Audiobibliothek (Audio-Tags Lesen, Schreiben bei *.wav und *.flac).
Die relativ größte oder längste Erfahrung habe ich mit JavaScript und PHP, aber auch da muß ich schonmal die Dokumentation bemühen. Allerdings vermute ich, dass es etwas aufwändiger werden kann, für PHP eigene Methoden für das Schreiben der Audio-Tags zu entwickeln. Mit Java habe ich auch im Studium programmiert, vieles wirkte auf mich umständlich, aber immerhin dafür meist recht gut nachvollziehbar.

Zu JavaScript und passend zur Grundsatzdiskussion mal ein Beispiel, was m.E. dort die Anwendung enorm erleichtern kann: https://developer.mozilla.org/en-US/doc ... e_literals

@tobo, ein anschauliches Beispiel.

[Meillo]

Wenn man in der Shell so programmieren will wie in anderen Sprachen, dann ist all die Kritik berechtigt, denn das funktioniert nicht. Wenn man aber in der Shell so programmiert wie es der Denkweise der Shell entspricht und nur die Projekte damit realisiert, die auch dafuer geeignet sind, dann ist viel von der Kritik unbedeutend. Das Problem ist, dass die Leute Python/Perl/Java/usw. denken, damit aber Shell schreiben wollen. Das klappt nicht. Man muss so denken lernen wie die Sprache, die man verwendet, konzipiert ist, oder alternativ nur diejenigen Sprachen verwenden die so konzipiert sind wie man selber denkt.


Die Shell ist eigentlich fuer Programmaufrufe gemacht, Shell-Funktionen sind nur ein Performance-Hack, der nicht richtig in das Konzept passt, nur halbgar designt worden ist und dann nachtraeglich zu verbessern versucht wurde. Heutzutage geht da viel, wie tobo demonstriert, aber das sind letztlich alles Erweiterungen, die auf ksh und bash basieren. Wenn man das was man sonst als Funktionen hat, in separate Shellscripte auslagert passt das alles besser zusammen. (Kommt mir jetzt nicht mit Performance!)

Dass die Shell nur Strings kennt kann man kritisieren oder annehmen. Ja, die Shell kennt nur Strings. Wer etwas anderes will, sollte sich eine andere Sprache suchen. Wer numerisch iterieren will ist bei der Shell an der falschen Stelle. In der Shell iteriert man ueber Eingabezeilen. Das ist eine andere Herangehensweise, eine andere Denkweise die Probleme zu zerlegen und Loesungen aufzubauen. Arrays sind der Shell eigentlich fremd (sind halt spaeter mal auch noch rangeflanscht worden). In der Shell macht man Arrays als Zeilen in Dateien. (Kommt mir jetzt nicht mit Performance!)


Wer Shellprogrammierung als richtige Programmiersprache sehen will, muss sich auf die Bash oder Ksh festlegen und deren Funktionen und Erweiterungen dann auch nutzen. David Korn, der Entwickler der ksh, gibt gut zum Ausdruck, dass er die ksh als richtige Programmiersprache sieht (unter Beibehaltung der Kompatiblitaet zur sh). Wer sich hierfuer interessiert, dem sei das Buch ``The Kornshell: Command and Programming Language'' von Bolsky und Korn ans Herz gelegt. (Es enthaelt als Case Study eine MH-Implementierung in ksh.)

[swick]

Schau dir mal xonsh und PowerShell für Linux an. Damit hast du das beste aus beiden Welten. Gute Shells + gute Programmierunterstützung

[tobo]

Wenn man das was man sonst als Funktionen hat, in separate Shellscripte auslagert passt das alles besser zusammen.

Das geht auch mit Funktionen "oldstyle"!?

Code: Alles auswählen

f(){
    echo $i
}
i=0
echo $i
(i=42 f)
echo $i

Für bash (entgegen dash und mksh) muss man da sogar nicht mal eine Subshell bemühen. Und f lässt sich dann natürlich durch ein Modul ersetzen...

[curt123]

Und es wurde mehrmals die Skriptsprache Python empfohlen wenn er von neu anfaengt, aber auch gesagt er soll das verwenden was am besten zu ihm passt.

Also mal, was für mich neben der Unterstützung der Audio-Tags noch wichtig sein mag:
Gute Dokumentation etc., guter fehlerfreier Beispielcode. Idealerweise passend eine frei verfügbare (und Debian-kompatible) leistungsstarke IDE, aber auch einfache Möglichkeiten, Code am/im Terminal o.ä. zu versuchen.

Nun klicke ich mich von phyton.org den Links folgend von einer Werbeblase zur nächsten und finde neben mich jedenfalls nervenden Werbesprech Seiten mit Anmeldezwang und kommerzielle Angebote, die mich derzeit weniger interessieren:

Some sites offer in-browser coding for those who want to learn Python:

Ausserdem muß ich wohl meine Lese- und Schreibgewohnheiten deutlich ändern oder erweitern https://de.wikipedia.org/wiki/Python_%2 ... sprache%29 :

So werden beispielsweise Blöcke nicht durch geschweifte Klammern, sondern durch Einrückungen strukturiert.

Da kann ich erstmal nur Nachteile vermuten.

[tobo]

Nun klicke ich mich von phyton.org den Links folgend von einer Werbeblase zur nächsten und finde neben mich jedenfalls nervenden Werbesprech Seiten mit Anmeldezwang und kommerzielle Angebote, die mich derzeit weniger interessieren:

python.org ist ganz bestimmt eine herausragende Quelle, die deine benötigten Informationen auf einer Seite bündelt. Dass es da Seiten - mit Zusatzangebot - gibt, die eine kostenlose Registrierung erfordern und von python.org verlinkt werden, ist auch so nicht weiter verwunderlich, im Moment aber für dich zweitrangig.

So werden beispielsweise Blöcke nicht durch geschweifte Klammern, sondern durch Einrückungen strukturiert.

Da kann ich erstmal nur Nachteile vermuten.

Im Gegenteil, das unabdingbare Strukturelement der Einrückung zum Erzwingen von (syntaktisch) lesbarem Code ist bestimmt nicht nur für einen Anfänger von Vorteil. Allerdings muss man sich auch darauf einlassen wollen...

[curt123]

Im Gegenteil, das unabdingbare Strukturelement der Einrückung zum Erzwingen

Igitt...

(syntaktisch) lesbarem Code

Immerhin etwas

Allerdings muss man sich auch darauf einlassen wollen...

Am Terminal kann ich Version 2.7 und/oder 3.7.3 aufrufen, da kann ich mir schonmal was anschauen.