ubuntuusers.de

user_unknown schrieb:

RTFM: ☺

Sehr schön. Wo hast Du dieses M denn gefunden?

... allerdings ist es eingeklammert.

Ja das war mein Vorschlag, damit der Doppelpunkt für den nicht eingeklammerten Teil gilt.

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

Ja, im Prinzip ist das redundant. Ich fand halt das Beispiel auch so nett.

1
2

man bash
/tern sub

Durch die bash blättern dauert ja leider ewig, weswegen man sich die Zwischenüberschriften einprägen müsste, um da schnell was wiederzufinden.

Der Slash leitet im man-pager ja eine Suche ein, "tern sub" sucht nach "Pattern substitution", ohne dass man sich die Finger wundschreibt und das Gedächtnis mit der Information belastet, ob es ein kleines oder großes P ist.

UlfZibis schrieb:

Ja, im Prinzip ist das redundant. Ich fand halt das Beispiel auch so nett.

user_unknown schrieb:

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

Reihenfolge nun vertauscht.

UlfZibis schrieb:

Jetzt fehlt aber ein Beispiel für längere Suchbegriffe, find' ich schade.

Hab's mal wieder eingesetzt, und hoffe, keiner hat was dagegen.

Wie wäre es, im Abschitt "Zeichenketten bearbeiten" "Such-/Ersatzbegriff" durch "Such-/Ersatz(zeichen)kette" zu ersetzen? "Begriff" finde ich hier ziemlich komisch, vor allem, wenn es nur um ein Zeichen geht.

@UlfZibis: Teilzustimmung. Bei der Suche handelt es sich aber um ein Suchmuster, und es kann nicht schaden, durch den Begriff zu verdeutlichen, dass hier reguläre Ausdrücke verwendet werden können.

Mir sind in einem Abschnitt einige Details aufgefallen, die mir nicht gefallen.

Man kann das auch in eine einzige Zeile packen, falls man die Kommandos direkt auf der Kommandozeile verwenden muss. Ein Beispiel:

read -p "Programm A (a) oder B (b) starten? Geben Sie a oder b ein und die Eingabetaste, Abbruch mit jeder anderen Taste ... " kommando; if [ $kommando == 'a' ]; then starte_programm_a; elif [ $kommando == 'b' ]; then starte_programm_b; else echo "Abbruch."; fi

Hier wird der Benutzer aufgefordert a oder b einzugeben, dann wird das jeweilige Programm ausgeführt. Die Eingabeaufforderung und die if-Verzweigung werden in einer Zeile abgesetzt. Man muss zwischen die einzelnen Befehle hier dann immer einen Strichpunkt (";") setzen, um sie zu trennen.

1) Die Programmzeile ist so lang, dass sie unergonomisch ist. Man muss scrollen, um alles zu lesen.

2) Jedes Programm wird beim Aufruf gestartet. Es heißt auch nicht starte_cd, starte_ls usw. oder gar starte_programm_ls, sondern cd, ls usw. .

3) Hätte man das zu schreiben, wäre es kürzer das so zu tun:

1

read -p "Programm (g)imp oder (i)nkscape starten? Geben Sie g oder i ein und die Eingabetaste, Abbruch mit jeder anderen Taste ... " kommando; if [ $kommando == 'g' ]; then gimp; elif [ $kommando == 'i' ]; then inkscape; else echo "Abbruch."; fi

Die Programme gibt es wirklich; man umgeht die atypische Großschreibung von Programmnamen; allerdings wäre es immer noch nicht kurz.

4) Überhaupt gibt es ja zur Selektion von Optionen das viel elegantere, wenn auch nicht kürzere Selectkonstrukt, welches auch bislang nicht vorgestellt wurde. Dass Semikolons die Eingabe mehrerer Befehle erlauben gehört ja auch nicht unbedingt in den Abschnitt "Benutzereingaben", könnte also separat gezeigt werden; am besten mit einem Beispiel, wo man es tatsächlich verwenden würde.

1
2
3
4
5
6
7
8
9

select drive in "[Abbruch]" /dev/sd? 
do
  if (( 1==REPLY ))
  then 
    echo Abbruch
    break
  fi
  ls -l ${drive}* 
done

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

1) [Abbruch]
2) /dev/sda
3) /dev/sdb
4) /dev/sdd
#? 2
brw-rw---- 1 root disk 8, 0 Sep 29 21:54 /dev/sda
brw-rw---- 1 root disk 8, 1 Sep 29 21:54 /dev/sda1
brw-rw---- 1 root disk 8, 2 Sep 29 21:54 /dev/sda2
#? 3   
brw-rw---- 1 root disk 8, 16 Sep 29 21:54 /dev/sdb
brw-rw---- 1 root disk 8, 18 Sep 29 21:54 /dev/sdb2
brw-rw---- 1 root disk 8, 19 Sep 29 21:54 /dev/sdb3
#? 4
brw-rw---- 1 root disk 8, 48 Okt  8 20:54 /dev/sdd
brw-rw---- 1 root disk 8, 49 Okt  8 20:54 /dev/sdd1
#? 1
Abbruch

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

select zutat in ESC wurst käse nussnougatcreme
do
  echo -n ${zutat^}brot "ist "
  case $zutat in
	ESC) echo Abbruchbedingung;
		break # Break ein wenig hervorgehoben aus didaktischen Gründen
		;;
        wurst) echo nicht vegetarisch ;;
        käse) echo nicht vegan ;;
        nussnougatcreme) echo evtl. nicht laktosefrei ;;
        *) echo Brot pur, ja? ;;
  esac
done

1

for strom in in out err warn; do ls /dev/std$strom; done 

1
2
3
4

/dev/stdin
/dev/stdout
/dev/stderr
ls: Zugriff auf '/dev/stdwarn' nicht möglich: Datei oder Verzeichnis nicht gefunden

user_unknown schrieb:

@UlfZibis: Teilzustimmung. Bei der Suche handelt es sich aber um ein Suchmuster, und es kann nicht schaden, durch den Begriff zu verdeutlichen, dass hier reguläre Ausdrücke verwendet werden können.

Also ein Suchmuster ist ja immer eine Zeichenkette.

Und "Such-/Ersatz(zeichen)muster" fände ich immer noch besser als "Such-/Ersatzbegriff".

user_unknown schrieb:

Mir sind in einem Abschnitt einige Details aufgefallen, die mir nicht gefallen.

Man kann das auch in eine einzige Zeile packen, falls man die Kommandos direkt auf der Kommandozeile verwenden muss. […]

Darum geht es in diesem Abschnitt: Befehle auf der Kommandozeile in einer Zeile aufreihen. Es geht nicht um den Befehl read und auch nicht um die Selektion von Benutzereingaben. Überhaupt ist die Verwendung von read auf der Kommandozeile praxisfremd.

Ein besseres, weil für die Praxis taugliches Beispiel wäre z.B.:

reboot; exit 

[…] Selectkonstrukt […]

Wenn der Befehl select im Artikel noch nicht beschrieben wurde, wäre es kontraproduktiv, ihn als Beispiel zu verwenden. Grundsätzlich möglich wäre seine Behandlung in einem neuen Abschnitt in diesem Artikel.

Allerdings: Der Artikel hat nicht den Anspruch, jedes Sprachkonstrukt von bash zu beschreiben, sondern wendet sich an Anfänger und will diesen eine Einführung in die Programmierung bzw. Benutzung der Shell geben. Ein Anfänger benötigt select zunächst einmal nicht und deshalb widerrate ich zu einem Abschnitt über select in diesem Artikel.

UlfZibis schrieb:

user_unknown schrieb:

@UlfZibis: Teilzustimmung. Bei der Suche handelt es sich aber um ein Suchmuster, und es kann nicht schaden, durch den Begriff zu verdeutlichen, dass hier reguläre Ausdrücke verwendet werden können.

Also ein Suchmuster ist ja immer eine Zeichenkette.

Ja, trivial, eine geschriebene Zahl ist auch eine Zeichenkette.

Und "Such-/Ersatz(zeichen)muster" fände ich immer noch besser als "Such-/Ersatzbegriff".

Du kannst nach einem Muster suchen - nicht selten ist das Suchmuster nur genau die Zeichenkette, die man eingetippt hat - aber der Ersatz kann kein Muster sein, im Kontext von Braceexpansion (im Ggs. zu sed beispielsweise, wo es Ersetzungsmuster gibt, etwa 's/foo([0-9]+)/bar\1/'). "Suchmuster" ist wahrscheinlich für die, die keine RegExps kennen, irritierend, die nur genau eine Zeichenkette finden wollen, die u.U. auch mit "Begriff" meist gut bezeichnet ist, andererseits auch gelegentlich nicht, insbesondere wenn nur Teile eines Begriffs oder begriffsübergreifende Zeichenketten gesucht werden, Satzzeichen oder Sonderzeichen.

Ein einziger Begriff, der für jeden im Publikum optimal ist, wird es kaum geben. Ich schlage mal die Kombination "Suchmuster/Ersatztext" vor, in der Hoffnung das Publikum versteht, dass auch Ziffern, Sonderzeichen usw. mitgemeint sind.

kB schrieb:

user_unknown schrieb:

Mir sind in einem Abschnitt einige Details aufgefallen, die mir nicht gefallen.

Man kann das auch in eine einzige Zeile packen, falls man die Kommandos direkt auf der Kommandozeile verwenden muss. […]

Darum geht es in diesem Abschnitt: Befehle auf der Kommandozeile in einer Zeile aufreihen. Es geht nicht um den Befehl read und auch nicht um die Selektion von Benutzereingaben.

Von den Zwischenüberschriften der Struktur ging es um "Interaktion mit dem Benutzer", Unterpunkt: "Einlesen von Eingaben", nicht um Codelayout. Jetzt hast Du den Einzeiler ersatzlos verworfen.

Zum Haupt- wie Unterpunkt würde der select-Befehl prima passen. Ich stimme zu, dass nicht alles, was die Bash bietet, in den Artikel kann.

(...) Überhaupt ist die Verwendung von read auf der Kommandozeile praxisfremd.

Ja? Ich vermute insofern, als man auf der Kommandozeile ja meist interaktiv/live arbeitet, und da beispielsweise ein Portnummer gleich eintippen kann, statt sie von sich selbst interaktiv erst zu holen mit aufwendigem Prompt. Wobei das Holen in einer Schleife nützlich sein könnte, oder wenn man ein Script schreibt, dass man es überhaupt mal interaktiv testen will, und bei Scripten ist read nicht praxisfremd, so dass es sehr rational ist, insbesondere beim Erlernen der Bash - und darum geht es in dem Artikel doch - das auch mal interaktiv zu benutzen.

Ein besseres, weil für die Praxis taugliches Beispiel wäre z.B.:

reboot; exit 

Eine große Freude, sicher, für Leute die mit verminderter Aufmerksamkeit alles mögliche in die Shell kopieren und ohne Nachdenken "Enter" drücken.

[…] Selectkonstrukt […]

Wenn der Befehl select im Artikel noch nicht beschrieben wurde, wäre es kontraproduktiv, ihn als Beispiel zu verwenden. Grundsätzlich möglich wäre seine Behandlung in einem neuen Abschnitt in diesem Artikel.

Allerdings: Der Artikel hat nicht den Anspruch, jedes Sprachkonstrukt von bash zu beschreiben, sondern wendet sich an Anfänger und will diesen eine Einführung in die Programmierung bzw. Benutzung der Shell geben. Ein Anfänger benötigt select zunächst einmal nicht und deshalb widerrate ich zu einem Abschnitt über select in diesem Artikel.

Also Anfänger können ja viele sein: Blutige Anfänger, Shellanfänger, Bashanfänger, Linuxanfänger. Man könnte auch manches noch löschen mit dem Argument, dass ein Anfänger das nicht braucht. Dafür spricht m.E. nur, dass ein zu langer Artikel vielleicht vom Lesen abschreckt. Andererseits können interessante Beispiele auch zum Verstehen/Ausprobieren/Lernen animieren.

Die select-Anweisung würde auch zu den 3 Schleifentypen inhaltlich passen und nach der Vorstellung von case/esac besser aufgehoben sein, als davor bei den Benutzereingaben, von wo aus man aber dahin linken könnte.

Mein Seelenheil hängt aber auch nicht davon ab, dass wir select vorstellen.

user_unknown schrieb:

[…]

Alles was Du schreibst, klingt plausibel und es sind vernünftige Standpunkte. Ich stimme Dir trotzdem nicht in allen Details vorbehaltlos zu, ohne das Bedürfnis, dies ausdiskutieren zu wollen.

Ich halte select in einem Artikel, der sich an Anfänger wendet, für entbehrlich. Das bedeutet natürlich nicht ein Verbot, den Artikel in diese Richtung zu ergänzen. Ich rate aber davon ab, weil der Artikel bereits sehr umfangreich ist.

Mein Seelenheil hängt aber auch nicht davon ab, dass wir select vorstellen.

In dem Punkt scheinen wir uns völlig einig zu sein.

Gut, dann eben nicht.