ubuntuusers.de

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