RootForum Community

Hallo,

ich fing gestern damit an, mich mit diesem Guide hier ausseinander zu setzen:
http://tldp.org/LDP/abs/html/abs-guide.html

Zunächst war ich erstaunt darüber, was Bash Scripting den alles zu bieten hat. Dann gings irgendwann los, wie man Strings manipuliert u.s.w. .

Der Syntax allgemein ist dabei nicht wirklich angenehm und genau deshalb frage ich mich: Muss das überhaupt sein?! Für "komplexe" Themen wie Strings manipulieren, Files verarbeiten, ... ,.. gibt es auch Scriptsprachen wie Python, mit denen das viel einfacher geht.

Der Sinn vom Bash-Scripting: Wiederkehrende (meist recht simple) Aufgaben besser/automatisiert erledigen können. Dazu brauche ich keine Möglichkeiten Strings zu manipulieren u.s.w. Falls doch, kann ich mir genauso ein Python Script basteln und Python ist da meiner Meinung nach viel angenehmer.

Liege ich damit falsch? Gibt es ein wirklich überzeugendes Argument, warum ich mich damit doch sehr intensiv ausseinander setzen sollte?

Danke Matze, deine Posgings sind immer wieder sehr hilfreich :)

Für normale DB Dumps und sonstige Sicherungen verwendete ich zuvor schon Bash Scripting. So gehts auch schnell und unkompliziert.

Der Vorteil, ich benötige keine Perl, Pyton etc. Installation.

Das ist mir bewusst, Python ist jedoch bei so ziemlich jeder Distro dabei ;)

Als Admin ist die shell mein tägliches Handwerkzeug. Diese zu beherrschen meiner Meinung nach eine absolutes muss. Dazu gehört natürlich auch das Schreiben von simplen Scripten und die Verarbeitung von Daten / Strings.

Als Entwickler sollte man auch diese ebene beherrschen, bevor man sich dann an "höhere" Sprachen wendet.

Ja, ein Grundverständnis ist wichtig, um gewisse Abläufe besser verstehen zu können. Da hast du damit schon Recht, dass man auch diese Ebene beherschen sollte, jedoch habe ich von dem Guide eben auch diese Zeile in Erinnerung:

When not to use shell scripts:
Resource-intensive tasks, especially where speed is a factor (sorting, hashing, recursion [2] ...)

Und genau deshalb fragte ich mich, warum ich Bash-Scripting jemals fürs Verarbeiten von Daten einsetzen sollte. Deine Aussage mit sed überzeugt mich hingegen schon eher.

Nun gut, den Guide einfach durchlesen und einige Beispiele durchmachen, wird mich wohl kaum ans Ziel führen. Also warte ich auf eine etwas umfangreichere Aufgabe, bei der ich das Wissen dann auch anwenden kann.

Gut, ich redete in meinem Fall auch nicht von Solaris ;)

Ein Klassiker wie Du ihn vermutlich suchst wäre z.B. das verarbeiten importieren, exportieren von Daten aus der DB:

Ja, ließ sich damals auch super einfach umsetzen - mit Python. :D Aber du hast schon recht, bei Python gibts da ja wieder den Interpreter.

Ich arbeite nicht mit komplexen Umgebungen, bei denen ich tausende Zeilen in eine DB importieren muss oder so. Hier gehts nur um den Lerneffekt, folglich benötige ich auch keine Strategien, wie ich den nun möglichst effizient einen DB Import durchführe. Trotzdem danke

Meine ursprüngliche Frage, ob es sich lohnt, sich so ins Bash Scripting zu vertiefen, wurde somit ja mehr als nur umfangreich beantwortet :)

Der Advanced-Bash-Scripting-Guide ist definitiv empfehlenswert und spätestens auf minimalistischen Rescue- oder Embedded-Systemen Gold wert, da in solchen Umgebungen im Allgemeinen keine ressourcenhungrige Interpreter gewünscht sind.
Man sollte allerdings bedenken, dass, trotz aller Mühe der Autoren, leider nicht an allen Stellen auf etwaige Inkompatibilitäten mit anderen gängigen Shells hingewiesen wird. Andererseits dürften schätzungsweise 90% des Guide auf alle gängige Shells (Ausnahme: dash) anwendbar ist.

Kurz: Ich kann den ABSG jedem Anfänger bis Profi uneingeschränkt empfehlen.

Der Advanced-Bash-Scripting-Guide ist definitiv empfehlenswert

Damit rechnete ich auch, du bist ja immerhin meine Quelle ;) Entdeckte diesen Link in einem Thread

Poste mal Deinen code und ich dir meinen um für eine Tabelle mit 3 Feldern die Daten als csv zu exportieren:

Der ist im Moment nicht in Reichweite und erfüllt den Zweck Staffelpreise (durch Reporting generiertes CSV) zu updaten, auszuwerten (oscommerce ProductID von dem Artikel ermitteln) und in die DB übertragen. Also nciht ganz vergleichbar - womit das mit Bash-Scripting vermutlich trotzdem kürzer geht.

Egal mit welcher Sprache, mit so wenig code bekommst Du das nicht hin.

Mir gehts nicht darum, wer wieviel Zeilen Code braucht. Ich gestalte meinen Code allgemein eher so, dass er auf jeden Fall gut lesbar ist. (gut, mit etwas Übung ist auch dein Shellscript gut lesbar)

Aber da ich gleich mal den Eindruck vermittle, als ob ich den Thread eröffnete, um Python zu verteidigen: Ihr habt mich längst überzeugt und ich werde mit dem Guide in nächster Zeit bestimmt einige Stunden/Tage verbringen

Danke, dieses Buch klingt für mich wirklich interessant, da es bestimmt viele kleine Helfer gibt, welche für mich bisher unentdeckt blieben -> ich werds mir bestellen

An der Stelle möchte ich mich nochmal allgemein für alle Antworten bedanken :)

Hmm, ich sehe das etwas lockerer. Ich arbeite viel mit Systemen, auf denen keine Bash zur Verfügung steht, sondern nur Bourne Shell Implementierungen, die noch rudimentärer als die Dash sind - in einigen Fällen habe ich mir schon Programme in C geschrieben weil ich am Skripting verzweifelt bin (FreeBSD im Single User Mode mit einem beschädigten TCSH-Binary) :evil:

Ich finde es schon lohnenswert, sich mit find, sed, xargs, grep und awk zu beschäftigen (aber bitte nicht mit dem Spezial-Firlefanz der GNU-Implementierungen), auch die grundlegende Bourne-Syntax (if, while, for, case, shift) sollte man draufhaben. Schon allein um ein zerschossenes System zu retten (Stichwort: Rettungssystem) oder mal eben schnell irgendwo Berechtigungen korrigieren zu können. Man muss aber nicht unbedingt Skripte schreiben können, die dem Prädikat "künstlerisch wertvoll" genügen

Ich halte es für durchaus legitim, komplexere Dinge (Logfile-Analyse, Lexer, Performance Monitoring) mit einer höheren Skriptsprache wie Python (oder Perl, wenn ich es denn könnte) zu erledigen. Das erhöht oft die Wiederverwendbarkeit, weil die Syntax wirklich einheitlich ist (im Gegensatz zu den x verschiedenen Bourne-Ablegern). Ach ja, auf meinen beiden Solaris-Systemen ist ein Python-Interpreter installiert :P

Ich ertappe mich selbst immer mal wieder dabei, dass ich ziemlich kranke Skript-Konstrukte baue - und dann jedesmal denke "verdammt, das hättest Du mit drei Zeilen Python sauberer hinbekommen". Wenn Du "künstlerisch wertvolle" Shell-Skripte findest, dann halte Dir einfach immer vor Augen, dass es (gerade im Admin-Umfeld) Leute gibt, die keine andere Sprache beherrschen. Jemand, der wirklich gut auf der Shell ist, wird damit bessere Monitoring-Skripte schreiben als jemand, der das mit rudimentären Perl-Kenntnissen in ebenjener Sprache versucht.

matzewe01 wrote:Ob man auf einer Rescue Umgebung grundsätzlich einen c Kompiler vorfinden wird?
Dabei propagieren "wir hier" compiler und co auf den Rootserver nicht drauf zu packen.

Zum ersten Punkt: das Programm habe ich natürlich auf einem anderen Rechner übersetzt und nur das Binary transferiert. Zum zweiten Punkt: darüber kann man sich trefflich streiten. Einige Systeme setzen einen Kompiler zwingend voraus, damit Updates überhaupt funktionieren (Gentoo, FreeBSD, OpenBSD, ...). Und ein Bösewicht braucht auf dem angegriffenen Rechner nicht unbedingt einen Kompiler, er kann sein Zeug auch auf seinem Rechner kompilieren. Mal abgesehen davon - um ein installiertes Programm benutzen zu können, muss man erst mal in den Rechner reinkommen, und wer eine PHP-Shell per XSS nachladen kann, der kann auch einen statisch gelinkten Kompiler nachladen.