staging.inyokaproject.org

user_unknown schrieb:

[…] Obwohl es nicht falsch ist würde ich es aus der Übersicht für Anfänger raushalten, weil weniger oft mehr ist. Man könnte so viele Techniken, so viele Grenzsituationen darstellen, kompliziertes Quoting, all die Einstellungen und Schlüsselwörter abhandeln; das ufert leicht aus.

Ja, eine valide Meinung. Andererseits ist ein Wiki ein kooperatives Gemeinschaftswerk und den sachlich richtigen Beitrag eines Benutzers zu unterdrücken deshalb unzulässig. Man kann eben unterschiedlicher Meinung sein, ob dieser spezielle Sachverhalt für Anfänger taugt oder nicht.

Es gibt kein festgelegtes Kriterium, was „für Anfänger“ definitiv bedeuten soll und somit in diesen Artikel gehört oder nicht. Eine Möglichkeit für eine Abgrenzung wäre, den Artikel zu überarbeiten und in zwei zu splitten, z.B.:

1. Bash-Skripting-Guide für Anfänger

2. Bash-Skripting-Guide für Fortgeschrittene

Der Artikel „für Anfänger“ würde dann für allgemeine Bearbeitung schreibgeschützt und damit das Niveau für Anfänger festgeschrieben. Ich werde nach meinem Urlaub den Gedanken weiter verfolgen und es müsste zu dieser Vorgehensweise auch ein Einvernehmen im Wiki-Team bestehen.

Eher würde ich vorschlagen in "Programmführung" das Schlüsselwort select vorzustellen

Sehe ich eher unter „Interaktion mit dem Benutzer“.

weil es so in anderen Programmiersprachen unbekannt ist.

Was zutrifft, aber kein Argument für „Anfänger-Niveau“ darstellt. Vielleicht gehört das doch eher in den noch nicht existierenden Artikel „Bash-Skripting-Guide für Fortgeschrittene“? Grundsätzlich sind aber Erweiterungen des Wikis durch willige und kompetente Autoren willkommen.

kB schrieb:

user_unknown schrieb:

[…] Obwohl es nicht falsch ist würde ich es aus der Übersicht für Anfänger raushalten, weil weniger oft mehr ist. Man könnte so viele Techniken, so viele Grenzsituationen darstellen, kompliziertes Quoting, all die Einstellungen und Schlüsselwörter abhandeln; das ufert leicht aus.

Ja, eine valide Meinung. Andererseits ist ein Wiki ein kooperatives Gemeinschaftswerk und den sachlich richtigen Beitrag eines Benutzers zu unterdrücken deshalb unzulässig. Man kann eben unterschiedlicher Meinung sein, ob dieser spezielle Sachverhalt für Anfänger taugt oder nicht.

Deswegen habe ich ja nicht den Artikel zurückgerollt und eine Änderungsnotiz hinterlassen, sondern meine Kritik hier in den Diskussionsartikel eingebracht - ich dachte wxpte würde hier mitlesen und sich dann melden, ich sollte ihn per PM zu diesem Thread einladen.

Es gibt kein festgelegtes Kriterium, was „für Anfänger“ definitiv bedeuten soll und somit in diesen Artikel gehört oder nicht. Eine Möglichkeit für eine Abgrenzung wäre, den Artikel zu überarbeiten und in zwei zu splitten, z.B.:

1. Bash-Skripting-Guide für Anfänger

2. Bash-Skripting-Guide für Fortgeschrittene

Ach Du liebe Zeit! ☺

Ich meine, es gibt ja einiges an freiem Material zum Bashscripten, manche Verlage haben ältere Versionen ihrer Bücher online, es gibt eigene Foren, SO, SE, zugegeben mehr auf Englisch. Man könnte endlos diskutieren, was zum Anfänger- und was zum Fortgeschrittenenstoff gehört und die Frage mit der Indizierung von Arrays ist auch nichts, was sich an der Demarkationslinie entzündet, sondern ob es guter Stil ist oder nicht.

Der Artikel „für Anfänger“ würde dann für allgemeine Bearbeitung schreibgeschützt und damit das Niveau für Anfänger festgeschrieben. Ich werde nach meinem Urlaub den Gedanken weiter verfolgen und es müsste zu dieser Vorgehensweise auch ein Einvernehmen im Wiki-Team bestehen.

Eher würde ich vorschlagen in "Programmführung" das Schlüsselwort select vorzustellen

Sehe ich eher unter „Interaktion mit dem Benutzer“.

weil es so in anderen Programmiersprachen unbekannt ist.

Was zutrifft, aber kein Argument für „Anfänger-Niveau“ darstellt. Vielleicht gehört das doch eher in den noch nicht existierenden Artikel „Bash-Skripting-Guide für Fortgeschrittene“? Grundsätzlich sind aber Erweiterungen des Wikis durch willige und kompetente Autoren willkommen.

Interaktion m.d. Benutzer ist aber auch kein Kriterium für Anf./Fortg. . Von der Struktur her ist es eine Verzweigung, ähnlich dem case-Statement, auch wenn es auch mit dem read verwandt ist. Und mir ist auch klar, dass es orthogonal zur Frage ist, ob man jetzt Arrays ab 1 diskutiert oder nicht und dass der, dem es zuerst fehlt, derjenige sein sollte, der sich überlegt, ob er es ergänzt. 😉

user_unknown schrieb:

... - ich dachte wxpte würde hier mitlesen und sich dann melden, ich sollte ihn per PM zu diesem Thread einladen.

Ja, den Beginn der Diskussion habe ich gestern Abend entdeckt, war zu diesem Zeitpunkt aber nicht mehr richtig aufnahmefähig (es war spät). Hmm, den Thread habe ich eigentlich schon seit längerem abonniert, da hätte doch auch eine Mail kommen müssen ....

Grundsätzlich war es mir erst einmal nicht bewusst, dass der Shift der Arrays um einen Zähler solche Probleme nach sich ziehen könnte; dass viele User Arrays zum Iterieren verwenden, hatte ich gar nicht auf dem Radar.

Dabei muss ich auch zugeben, dass ich in meinen Skripten den Array gar nicht auf die gezeigte Weise hochsetze, sondern mit dem Kommando readarray -O1. Ich hatte nur, nachdem ich diese Option entdeckt hatte, nochmals unter dem Abschnitt "Arrays" nachgelesen und ausprobiert, ob so etwas mit der eingeklammerten Zeile auch möglich ist. Da dies der Fall ist, wollte ich das Ergebnis dann auch der Community zukommen lassen.

Der Hintergrund, warum ich so etwas (Hochsetzen der Indizes) überhaupt mache, ist die Uneinheitlichkeit des Systems: das Kommando cut zählt die Felder ab Eins, die Parameter auch ($0 hat ja eine Sonderfunktion). Wenn ich dann während des Skriptens schnell in der strukturierten Datendatei etwas nachschauen möchte, greife ich meistens mit cut auf das betreffende Feld zu. Ich habe bis heute nicht verstanden, warum man es sich hat einfallen lassen, bei der Zählung von Arrayindizes mit Null zu beginnen, während man ansonsten die Eins als ersten Zähler verwendet.

Im Grunde genommen habt ihr aber beide Recht: zum Kernbereich eines Skripting-Guides gehört es wahrhaftig nicht. Daher mein Vorschlag: ich würde die Passage wieder aus dem Guide entfernen, ein wenig umformulieren und bei Tipps und Tricks an geeigneter Stelle unterbringen. Das schaffe ich aber frühestens heute Abend.

wxpte schrieb:

Ich habe bis heute nicht verstanden, warum man es sich hat einfallen lassen, bei der Zählung von Arrayindizes mit Null zu beginnen, während man ansonsten die Eins als ersten Zähler verwendet.

Ich vermute, weil im Speicher der Start des Arrays hinterlegt ist, und arr[i] dann leicht u. schnell an der Stelle arr[0] + (i * Elementsize) gefunden werden kann.

Im Grunde genommen habt ihr aber beide Recht: zum Kernbereich eines Skripting-Guides gehört es wahrhaftig nicht. Daher mein Vorschlag: ich würde die Passage wieder aus dem Guide entfernen, ein wenig umformulieren und bei Tipps und Tricks an geeigneter Stelle unterbringen. Das schaffe ich aber frühestens heute Abend.

Schön, dass Du reagiert hast und bei Tipps/Tricks ist es m.E. auch besser platziert. Eile hat es wohl nicht, wer weiß wie oft jmd. das überhaupt durcharbeitet.

Done.

Hallo in die Runde,

in diesem Abschnitt Shell/Bash-Skripting-Guide für Anfänger (Abschnitt „Variablen“) wird das folgende Beispiel genannt:

date +%A 

Der Parameter %A zeigt den ausgeschriebene Wochentag an

Meine Frage, so steht eine Erklärung für das +

In der manpage wird die Syntax wie folgt angezeigt:

date [OPTION]… [+FORMAT]

Formatangaben werden also grundsätzlich mit einem + eingeleitet. Die Befehlsübersicht verweist auf die manpage.

Berlin_1946 schrieb:

[…] Meine Frage, so steht eine Erklärung für das +

Das ist eine Besonderheit des Befehls date und natürlich in der Manpage von date erklärt.

Im angesprochenen Abschnitt des Wiki-Artikels geht es aber gar nicht um den Befehl date, sondern wie man unter Verwendung von Umgebungsvariablen die Ausgabe eines Befehls ändern kann. Vielleicht ist es nicht so geschickt, dafür ein selbst erklärungsbedürftiges Beispiel zu wählen.

Wenn jemand einen Wiki-Artikel zu date schreiben möchte, könnte man das Beispiel dahin verschieben oder den neuen Wiki-Artikel hier verknüpfen.

Ein anderes Beispiel für den hier erklärten Gebrauch wäre z.B.:

man man 

versus

LANG=C man man 

(Aber date als Beispiel ist natürlich hier cooler.)

kB schrieb:

Wenn jemand einen Wiki-Artikel zu date schreiben möchte, könnte man das Beispiel dahin verschieben oder den neuen Wiki-Artikel hier verknüpfen.

Eigentlich benutze ich diesen Befehl schon recht häufig (auch in meinen Skripten). So ein paar interessante Dinge ließen sich da schon ausführen; und wenn ich mir zum Vergleich den Artikel zu cat ansehe, dann ließe sich da schon etwas machen.

Ich werde mir mal ein paar Gedanken machen, ob ich genügend Material zusammen bekomme, das wesentlich über die recht anschaulich beschriebene manpage hinausreicht. Den Rest erledigt dann (hoffentlich) die Schwarmintelligenz.

Wenn ich zu dem Schluss komme, dass sich ein eigener Artikel zu date lohnt, dann melde ich mich.

kB schrieb:

Vielleicht ist es nicht so geschickt, dafür ein selbst erklärungsbedürftiges Beispiel zu wählen.

100% mein Anliegen. 👍

date +%A 

Der Parameter %A zeigt den ausgeschriebene Wochentag an

Mein Vorschlag:

date +%A 

Der Befehl date benötigt ein + vor den Parametern. %A ist der Parameter für den ausgeschriebene Wochentag. Weitere Informationen findet man in der Befehlsübersicht

Berlin_1946 schrieb:

Der Befehl date benötigt ein + vor den Parametern.

Besser: den Formatierungsparametern. Die anderen Parameter (z. B. Optionen) folgen dagegen den gewohnten Regeln.

Gegenvorschlag:

date +%A 

Formatangaben beim Befehl date muss ein + vorangestellt werden, %A steht für den ausgeschriebenen Wochentag. Weitere Informationen findet man in der Befehlsübersicht

Dieses Beispiel unter Shell/Bash-Skripting-Guide fC3BCr AnfC3A4nger (Abschnitt „Zeichenketten-bearbeiten“) funktioniert nicht, denn:

$ x='Das UbuntuUsers.de-Wiki ist toll.'
$ echo ${x/./ und wird immer besser.} 
Das UbuntuUsers und wird immer besser.de-Wiki ist toll.

Insofern wäre es interessant noch anzuführen, was man tun muss, wenn man das letzte passende Muster ersetzen will.

UlfZibis schrieb:

Dieses Beispiel unter Shell/Bash-Skripting-Guide fC3BCr AnfC3A4nger (Abschnitt „Zeichenketten-bearbeiten“) funktioniert nicht, …

Insofern wäre es interessant noch anzuführen, was man tun muss, wenn man das letzte passende Muster ersetzen will.

Ersetzt mit:

Natürlich kann man auch längere Such-/Ersatzbegriffe verwenden und der Ersatzbegriff darf auch leer sein, was zur Löschung des Suchbegriffs führt.

Mit ${v/#x/y} ersetzt man in der Variablen v x durch y nur, wenn x am Anfang der Zeichenkette steht, mit ${v/%x/y} nur am Ende:

v=nennen
echo $v ${v/#n/k} ${v/%n/r}
# nennen kennen nenner 

Das ist zwar nicht erstes/letztes Match, sondern Match am Zeichenkettenbeginn/-ende, aber dafür funktioniert/stimmt es. Auch der Doppelpunkt vor dem Code wurde entfernt, denn da kam ja kein Beispiel für einen leeren Ersetzungsstring.

user_unknown schrieb:

Ersetzt mit:

Natürlich kann man auch längere Such-/Ersatzbegriffe verwenden und der Ersatzbegriff darf auch leer sein, was zur Löschung des Suchbegriffs führt.

Jetzt fehlt aber ein Beispiel für längere Suchbegriffe, find' ich schade. Wie wär's mit:

Natürlich kann man auch längere Such-/Ersatzbegriffe verwenden (der Ersatzbegriff darf auch leer sein, was zur Löschung des Suchbegriffs führt):

x='Das UbuntuUsers.de-Wiki ist toll.'
echo ${x/toll/toll und wird immer besser} 

Das UbuntuUsers.de-Wiki ist toll und wird immer besser.

Mit ${v/#x/y} ersetzt man in der Variablen v x durch y nur, wenn x am Anfang der Zeichenkette steht, mit ${v/%x/y} nur am Ende:

Toll, dass Du das herausgefunden hast (ich konnte im Netz nämlich nix dergleichen finden), und schönes Beispiel.

Auch der Doppelpunkt vor dem Code wurde entfernt, denn da kam ja kein Beispiel für einen leeren Ersetzungsstring.

Da steht ja nicht nur was von "leerem Ersetzungsstring".

RTFM: ☺

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

       ${parameter/pattern/string}
       ${parameter//pattern/string}
       ${parameter/#pattern/string}
       ${parameter/%pattern/string}
              Pattern substitution.  The pattern is expanded to produce a pattern just as  in  pathname  expansion.
              Parameter  is  expanded  and  the longest match of pattern against its value is replaced with string.
              string undergoes tilde expansion, parameter and variable expansion, arithmetic expansion, command and
              process substitution, and quote removal.  The match is performed using the rules described under Pat‐
              tern Matching below.  In the first form above, only the first match is replaced.  If  there  are  two
              slashes separating parameter and pattern (the second form above), all matches of pattern are replaced
              with  string.   If pattern is preceded by # (the third form above), it must match at the beginning of
              the expanded value of parameter.  If pattern is preceded by % (the fourth form above), it must  match
              at  the  end of the expanded value of parameter.  If the expansion of string is null, matches of pat‐
              tern are deleted.  If string is null, matches of pattern are deleted and the / following pattern  may
              be omitted.

Wenn Du den Doppelpunkt wieder einfügst werde ich keinen Editwar führen. Das letzte Statement ist zum Leerstring, allerdings ist es eingeklammert.

Zwei Absätze weiter oben ("Abschneiden von Mustern") sind die Schnittmöglichkeiten mit einem längeren Suchstring gezeigt worden.