staging.inyokaproject.org

noisefloor schrieb:

welcher Editor unterstützt Syntachervorhebung?

Der Link auf Editoren ist gesetzt, dass reicht IMHO - sonst hätte man Redundanz 😉

Aus dem Link ergibt sich _nicht_, welcher Editor Syntaxhervorhebung bietet ☹

Vain schrieb:

skriptname vs. skriptname.sh: Ich hätte da prinzipiell denselben Gedanken wie track gehabt. Dass manche Editoren sich auf die Erweiterung verlassen, war mir aber gar nicht so bewusst.

Ich muss mich berichtigen, kate macht doch automatische Syntaxvervorhebung, egal ob mit .sh oder nicht. Wichtig ist nur das shebang. Sorry 😕

frustschieber schrieb:

Aus dem Link ergibt sich _nicht_, welcher Editor Syntaxhervorhebung bietet ☹

AFAIK können das alle Standardeditoren der Desktopumgebungen. gedit auch...

kaputtnik schrieb:

frustschieber schrieb:

Aus dem Link ergibt sich _nicht_, welcher Editor Syntaxhervorhebung bietet ☹

AFAIK können das alle Standardeditoren der Desktopumgebungen. gedit auch...

Mousepad und Leafpad können das nicht, aber sonst fast jeder Editor, selbst Nano. 😀

Vain schrieb:

Ausführbar machen: In chmod und Rechte steht was. Was genau sollte zu dem Thema noch gesagt werden?

Spezielle für diese Artikel eigentlich nichts, aber wenn man es in einen eigenen Artikel packen würde könnte man z.B. noch erwähnen, das man - zumindest in Ubuntu - eine Datei auch über die GUI ausführbar machen kann.

Übrigens würde ich den $PATH-Teil völlig raus nehmen, weil es für Anfänger und den Rahmen dieses Artikels ausreicht, wenn man das Skript entweder aus dem entsprechenden Verzeichnis heraus ausruft oder durch Angabe des Gesamtpfades. Oder man macht so eine Darstellung am Ende des Artikels in eine Rubrik praktische Tipps. Hier am Anfang finde ich es zu verwirrend.

Quoting: Ich finde nicht, dass ein einfaches echo ausreicht, um das zu erklären.

Mal abgesehen davon, dass man wie gesagt immer gute und schlechte Gründe für eine Platzierung finden kann, wollte ich nicht sagen, dass sich zusammen mit echo alle Belange des Quotings darstellen lassen, die Grundzüge aber schon. Du hast ja bei Deinen Beispielen auch fast alles mit echo erklärt. Es lässt sich auf jeden Fall schon mal das mit Leerzeichen und Zeilenumbrüchen erklären und auch, dass es Sonderzeichen gibt.

Anderer Aufbau-Vorschlag:

1. Ausgabe mit echo, ohne auf Leer- und Sonderzeichen einzugehen.

2. Variablen abhandeln, ohne auf Leer- und Sonderzeichen einzugehen.

3. Behandlung von Leer- und Sonderzeichen - und damit das Thema Quoting und Maskierung.

Die Formulierungen im Abschnitt Quoting müssen noch an vielen Stellen präzisiert werden. Da es einfache und doppelte Anführungszeichen beim Quoting gibt, dann im Text auch immer entsprechend von einfachen oder doppelten Anführungszeichen sprechen und nicht nur Anführungszeichen.

Am besten ein Abschnitt doppelte Anführungszeichen und ein Abschnitt einfache Anführungszeichen.

Gruß, Martin

EDIT:

Kurze Definition am Anfang: z.B.

Ein Bash-Skript ist eine Datei mit mindestens einem oder mehreren Bash-Befehlen, die beim Ausführen der Datei vom Bash-Interpreter der Reihe nach abgearbeitet werden. Bash-Skripte eigenen sich daher gut, um immer wiederkehrende Befehlsfolgen abzuspeichern. Durch Zurückgreifen auf Programm-Anweisungen und Funktionen, lassen sich so außerdem sehr komplexe Problemstellungen lösen.

Variablen - Teil 2:

Dieser Abschnitt passt erstens nicht an diese Stelle sondern würde wenn zu "Quting" gehören. Wenn sich der Einsatz eh nicht empfiehlt, dann kann man IMO auch gleich ganz darauf verzichten - was ich im Rahmen eines Anfänger-Artikels für vertretbar halte. Also entweder Backticks im Bereich "Quoting" erklären oder ganz darauf verzichten. So ist es jedenfalls verwirrend.

Es ist eine gute Gewohnheit, Variablen immer in Gänsefüßchen einzuschließen, auch wenn man das bei echo nicht grundsätzlich braucht.

Dabei muss man zwischen den einfachen und den doppelten Gänsfüßchen unterscheiden. Bei "..." werden z.B. Variablen expandiert, bei '...' nicht.

Auch das gehört nicht so recht an diese Stelle, sondern noch zum "Quoting". Außerdem würde ich einfach nur schreiben:

Es ist eine gute Gewohnheit, Variablen immer in Gänsefüßchen einzuschließen, weil...

auch wenn man das bei echo nicht grundsätzlich braucht.

Dieser Teil ist überflüssig wenn man etwas empfiehlt und verwirrt nur. Also einfach ganz mutig etwas empfehlen mit kurzer Begründung.

Aus meiner Sicht wird hier nicht ganz klar, auf was sich "auf diese Weise" beziehen soll.

Arrays:

Arrays lassen sich hervorragend über Schleifen verarbeiten, was etwas weiter unten noch beschrieben wird.

Wenn es geht, sollte man auf Verweisungen nach unten verzichten. Und hier geht es, ohne dass dadurch dem Leser etwas verloren geht. Außerdem wird weiter unter im Moment noch gar nichts mit Arrays und Schleifen erklärt. Oder warst Du noch gar nicht so weit?

Wie auch immer den Verweis auf "weiter unten" kann man sich sparen.

Gruß, Martin

EDIT 2:

Parameter an ein Skript übergeben:

Mehrere Befehle können durch doppelte Und-Zeichen "&&" zu kurzschließendenn Tests verbunden werden, d.h. bei mehreren, mit && verbundenen Tests wird die Auswertung abgebrochen, sobald ein Teilausdruck falsch ist, weil dann der Gesamtausdruck falsch ist; umgekehrt wird bei mehreren veroderten Tests (||) abgebrochen, sobald einer wahr ergibt, da dann der Gesamtausdruck wahr ergibt. Dies kann Zeit sparen, wenn spätere Tests ignoriert werden können, aber mit Überraschungen verbunden sein, wenn man nicht berücksichtigt, das spätere Tests Seiteneffekte haben sollen, die dann auch übersprungen werden.

Diese Erklärung geht hier IMO etwas unter und sollte in den Abschnitt "Das Test-Kommando", weil das ja generell in dem Zusammenhang hilfreich ist und nicht nur bei der Parameterübergabe.

Gruß, Martin

Da stand zuvor, sinngemäß, 'Heutzutage' seien alle Zeichenfolgen in Dateinamen erlaubt... - Wenn man heutzutage unter Linux arbeitet, und zuvor mit Windows? ☺

Hier stand, die farbige Ausgabe von ls verursache womöglich Forkbomben. Bitte vormachen. - Nein, im Ernst: Nur im interaktiven Modus macht die Shell die Dateinamen bunt. Die anderen zwei Punkte habe ich in einem Aufwasch umformuliert.

Wollte nur mal kurz Bescheid geben, dass ich derzeit keine Zeit mehr habe, um großartig am Artikel weiterzumachen. Das wird sich in den nächsten Monaten auch leider nicht mehr ändern.

Sorry dafür, dass ich da jetzt so viel rumgewühlt habe und es nun halb fertig liegen lasse. 😬

Vain schrieb:

Wollte nur mal kurz Bescheid geben, dass ich derzeit keine Zeit mehr habe, um großartig am Artikel weiterzumachen. Das wird sich in den nächsten Monaten auch leider nicht mehr ändern.

Sorry dafür, dass ich da jetzt so viel rumgewühlt habe und es nun halb fertig liegen lasse. 😬

Kein Problem; ich hoffe ein erfreulicher Anlaß (Kohle scheffeln, Doktorarbeit, Brautschau, Nachwuchs, ...). ☺

Ja, keine Sorge, ist erfreulich. 😉 Schränkt nur messbar die Freizeit ein.

Schade, aber der Link zu awk unter http://wiki.ubuntuusers.de/Baustelle/Shell/Bash-Skripting-Guide_f%C3%BCr_Anf%C3%A4nger#Rechnen-mit-der-Shell führt leider in's Leere.

Die Homepage war umgezogen, aber der Artikel ist selbst dort noch falsch verlinkt (führt zu der hier angegebenen URL).

Ryu

Hab den Webmaster von der Uni mal angeschrieben. Mal sehen, was sich da tut. 🤓

Vielleicht kann man diesen Externen Guide noch unten verlinken? http://de.wikibooks.org/wiki/Linux-Kompendium:_Shellprogrammierung

mha93 schrieb:

Vielleicht kann man diesen Externen Guide noch unten verlinken? http://de.wikibooks.org/wiki/Linux-Kompendium:_Shellprogrammierung

Dieser Artikel dient als Ergaenzung zu Bash. Der von Dir genannte Link ist dort bereits vorhanden.

aasche schrieb:

mha93 schrieb:

Vielleicht kann man diesen Externen Guide noch unten verlinken? http://de.wikibooks.org/wiki/Linux-Kompendium:_Shellprogrammierung

Dieser Artikel dient als Ergaenzung zu Bash. Der von Dir genannte Link ist dort bereits vorhanden.

Ok, danke.

Hi!

Sollte der jetzt vielleicht mal zurück? Vain scheint ja keine Zeit mehr zu haben... Avisiertes Fertigstelldatum war der 30.04.

so long
hank

Moinsen

Heinrich Schwietering schrieb:

Sollte der jetzt vielleicht mal zurück?

Unfertig zurück wäre unschön. Inhaltlich hat die Überarbeitung schon viel gebracht (zumindest stellen sich beim Überfliegen nicht mehr meine Nackenhaare auf). Die persönliche Anrede muss noch raus und einige Kleinigkeiten sind sicherlich noch zu tun. Auf Grund des Umfangs des Artikels und weil es kein triviales Thema ist, bin ich dafür die Baustelle etwas länger als üblich liegen zu lassen. Irgendwann muss ich die Überstunden, die ich derzeit mache auch wieder abfeiern und dann werde ich versuchen die Überarbeitung im Sinne des Bearbeiters abzuschließen.

Gruß, cornix