Macro in Bash

[owl102]

Code: Alles auswählen

    echo "$1" | sed -e "s/$2[^<>]*$3/$4"/g; /^[ ]*$/d"

Wenn man bash benutzt, kann man auch "here strings" benutzen:

Code: Alles auswählen

 sed ... <<< "$1"

Und wenn man kein bash, sondern POSIX benutzt, sollte man "echo "$1"" nicht als generischen Input verwenden, da es sein kann, daß das echo der Shell Dinge innerhalb der Zeichenkette interpretiert. Stattdessen besser "printf "%s\n" "$1" verwenden.

[Lohengrin]

Wenn man bash benutzt, kann man auch "here strings" benutzen:

Code: Alles auswählen

 sed ... <<< "$1"

Ja. Ist ganz nett. Aber ich ärgere mich über Emacs. Sobald ich << getippt habe, haut der mit zwei EOF da hin und setzt den Curor dazwischen. Das muss ich dann erst wieder wegmachen.

Und wenn man kein bash, sondern POSIX benutzt, sollte man "echo "$1"" nicht als generischen Input verwenden, da es sein kann, daß das echo der Shell Dinge innerhalb der Zeichenkette interpretiert. Stattdessen besser "printf "%s\n" "$1" verwenden.

Das war mir vorgestern noch nicht klar. Danke für den Hinweis! Ich werde es in Erinnerung behalten.

[raa]

Die $strLeftMarg, $strRightMarg und $strSub sind nackt. Wenn die Leerzeichen oder Tab drin haben, hast du ein Problem.

Nein. (Schon ...zigmal getestet.) Der Fallstrick lauert woanders, bei '.' und '/' - Abhilfe:

Dann vermute ich, dass es bei dir in der Funktion so aussieht, und die $1 $2 $3 $4 in in Gänsefüßen sind.

Code: Alles auswählen

replPartStrings () {
    echo "$1" | sed -e "s/$2[^<>]*$3/$4"/g; /^[ ]*$/d"
}

So etwa. In der Library:

Code: Alles auswählen

# Teilstring "$strPart" durch "$strPartRep" ersetzen
# Achtung: Punkte in "$strPartRep" maskieren: '\\.', sonst werden sie als Platzhalter interpretiert
# Option: Steuerzeichen, das im String nicht vorkommt (default: '/')
replChars () { #RV strRep #A "$str" "$strPart" "$strPartRep" 'optChrCtrl'

	chrCtrl=/; [ $4 ] && chrCtrl=$4
	echo "$1" | sed s"$chrCtrl$2$chrCtrl$(maskSpecChars "$3")$chrCtrl"g
}

Im Katalog sieht das dann so aus:

http://hkraus.eu/replChars.png

maskSpecChars () (Sonderzeichen '\' '&' maskieren) ist natürlich auch eine Funktion ... Frag' mich also mal, warum ich nicht auch aus "Punkte maskieren" eine gemacht habe. Wem das gelingt, der möge sich bitte melden.

Der Vollständigkeit halber: Die erste Zeile in meinen Scripten lautet selbstverständlich immer

Code: Alles auswählen

#!/bin/bash

[Meillo]

Aber ja: Wenn man keine Kompatiblitaet braucht, dann kann man verwenden, was einem selbst am sinnvollsten erscheint.

Das hört sich so an, als könnte man sich nur dann für die Bash entscheiden, wenn man keine Kompatibilität benötigt.

Aber auch ich will Kompatibilität; meine Skripte sollen unter RHEL/CentOS 7, Fedora, Debian 9 und openSuse laufen, und einige auch auf meinem Illumos-basiertem Server (OmniOS). Und deswegen habe ich mich bewußt für "!/bin/bash" entschieden.

Wie man sieht: Eine individuelle Entscheidung, basierend auf der Kompatibilität, die ich benötige. Deswegen störe ich mich auch immer an Sätzen wie "Und für höhere portabilität kein bash sondern bourne shell verwenden...", denn ohne zu wissen, was für Kompatibilität der Autor/Fragestellung überhaupt benötigt ist so ein Ratschlag IMHO einfach Käse. (Und "bourne shell verwenden" bedeutet, nicht einmal POSIX einsetzen zu dürfen, da die Bourne Shell einige POSIX-Features nicht bietet, wie z.B. "test -e" oder "test -L". [1] Aber der Autor dieser Zeile hat auch recht, man wäre dann zu noch mehr/älteren Unix-Systemen kompatibel, als wenn man POSIX einsetzen würde.)

[1] Quelle: http://mywiki.wooledge.org/BashFAQ/004

Gut, dass du nachhakst. Ich habe es nicht so gemeint wie es sich scheinbar auch anhoeren koennte. Im Gegenteil, ich stimme allen deinen Aussagen in diesem Post zu.

[Meillo]

Der Vollständigkeit halber: Die erste Zeile in meinen Scripten lautet selbstverständlich immer

Code: Alles auswählen

#!/bin/bash

Sollte sie nicht vielleicht besser

Code: Alles auswählen

#!/usr/bin/env bash

lauten?

[raa]

Der Vollständigkeit halber: Die erste Zeile in meinen Scripten lautet selbstverständlich immer

Code: Alles auswählen

#!/bin/bash

Sollte sie nicht vielleicht besser

Code: Alles auswählen

#!/usr/bin/env bash

lauten?

Klar, man kann's auch übertreiben.

[raa]

Und wenn man kein bash, sondern POSIX benutzt, sollte man "echo "$1"" nicht als generischen Input verwenden, da es sein kann, daß das echo der Shell Dinge innerhalb der Zeichenkette interpretiert.

Och, die bash ist auch äußerst interpretationsfreudig. Aber bei

Code: Alles auswählen

echo $irgendeinString | sed  sonstwas

interpretiert erst sed, kannste mir glauben.

Code: Alles auswählen

echo $irgendeinString

liefert allerdings an Stelle mehrerer aufeinanderfolgender Blanks jeweils nur eins, jedenfalls bei mir ...

[owl102]

Klar, man kann's auch übertreiben.

Ich empfinde das als einen guten und berechtigten Punkt und nicht als Übertreibung.

Ist auch in [1] und [2] zu finden. Dort findet sich übrigens auch ein IMHO guter Abschnitt "Choose Your Shell".

[1] http://mywiki.wooledge.org/BashGuide/Practices
[2] http://mywiki.wooledge.org/BashProgramming

[Meillo]

Code: Alles auswählen

echo $irgendeinString

liefert allerdings an Stelle mehrerer aufeinanderfolgender Blanks jeweils nur eins, jedenfalls bei mir ...

Das ist auch korrekt so. Ist jedem (der Nicht-Profis) klar, warum das so ist?

... und es zeigt schoen, warum es sinnvoll ist, Variablenexpansionen normalerweise zu doublequoten.

[raa]

Klar, man kann's auch übertreiben.

Ich empfinde das als einen guten und berechtigten Punkt und nicht als Übertreibung.

Ich schon. Was ist denn der Unterschied? "Weiß" das OS sonst nicht, dass es als Umgebung für das Script eine Instanz der bash starten muss?

[raa]

Code: Alles auswählen

echo $irgendeinString

liefert allerdings an Stelle mehrerer aufeinanderfolgender Blanks jeweils nur eins, jedenfalls bei mir ...

Das ist auch korrekt so. Ist jedem (der Nicht-Profis) klar, warum das so ist?

Naja, mir im Moment noch etwa zur Hälfte, sagen wir mal.

... und es zeigt schoen, warum es sinnvoll ist, Variablenexpansionen normalerweise zu doublequoten.

Richtig, es sei denn, man will es so. Und ich kann's öfters so gebrauchen.

[RobertDebiannutzer]

Das ist auch korrekt so. Ist jedem (der Nicht-Profis) klar, warum das so ist?

Ja, ist nicht in doublequotes. Hintergrund ist AFAIK, dass die Shell ohne quotes interpretiert und für die Interpretation sind "überflüssige" zusätzliche Leerzeichen irrelevant, weshalb sie einfach entfallen. (So wie z.B. bei

Code: Alles auswählen

cp    -a        file    file2

.)

Wenn man absichtlich keine Anführungszeichen nutzt, muss man extrem vorsichtig sein.
Ich nutze z.B. in meinem neuen backup-Script (welches noch in der Testphase ist), an einer Stelle keine Anführungszeichen, da hier ein for-loop über die durch Leerzeichen getrennten Elemente iterieren soll (s. loop am Ende):

Code: Alles auswählen

#!/bin/bash
[...]
usage () {
	echo -e "\
Usage: $0 -r <device> [-p <device>...] -u <device> -m <directory>

Arguments:
   -r <device>       root partition
   -p <device>...    other partitions (quote when more than one!)
   -u <device>       usb device
   -m <directory>    mountpoint for usb device

Example:
   $0 -r /dev/sda2 -p \"/dev/sda3 /dev/sda4 /dev/sda5\" -u /dev/sdb1 -m /mnt/tmp

Note:
   Except the option '-p', all options are mandatory.\
"
}
# END: functions


c=0
while getopts r:p:u:m: opt; do
	case "$opt" in
		r) rootpart="$OPTARG" && ((c++));;
		p)
			parts="$OPTARG"
			if [ -z "$parts" ]; then
				usage "$0"; exit 1
			fi
			;;
		u) usb="$OPTARG" && ((c++));;
		m) mountpoint="$OPTARG" && ((c++));;
		\?) usage "$0" && exit 1;;
	esac
done
[...]
# mount $parts
for i in $parts; do
	echo "Mounting $i ..."
	mount_cmd "$i"
	if [ $? -ne 0 ]; then
		echo "ERROR: failed to mount $i."
		umount_cmd
		exit 1
	else
		echo "$i mounted."
	fi
done
[...]

[owl102]

Was ist denn der Unterschied?

Die bash könnte z.B. nicht in /bin, sondern auf einem Nicht-Linux in /usr/local/bin liegen. Siehe auch: https://stackoverflow.com/questions/163 ... r-bin-bash

[Meillo]

Code: Alles auswählen

echo $irgendeinString

liefert allerdings an Stelle mehrerer aufeinanderfolgender Blanks jeweils nur eins, jedenfalls bei mir ...

Das ist auch korrekt so. Ist jedem (der Nicht-Profis) klar, warum das so ist?

Naja, mir im Moment noch etwa zur Hälfte, sagen wir mal.

Nehmen wir an, dass zuvor

Code: Alles auswählen

irgendeinString="foo  bar    baz"

gesetzt wurde.

1) Die Shell liest eine Zeile:

Code: Alles auswählen

echo $irgendeinString

2) Die Shell expandiert die Variable:

Code: Alles auswählen

echo foo  bar    baz

3) Die Shell macht Word-Splitting:

Code: Alles auswählen

"echo" "foo"  "bar"    "baz"

4) Die Shell forked und ruft per exec() /bin/echo mit einem argv von vier Strings ("echo", "foo", "bar", "baz") auf.

5) echo(1) gibt jedes seiner Argumente Leerzeichen getrennt aus.

The echo utility arguments shall be separated by single <space> characters and
a <newline> character shall follow the last argument.

(Diese Beschreibung unterschlaegt ein paar Details, sollte aber im Groben verstaendlich machen, was passiert.)

Wenn man die Variablenexpansion quoten wuerde, saehe Schritt 3 so aus:

Code: Alles auswählen

"echo" "foo  bar    baz"

. Und in Schritt 4 haette argv nur zwei Strings.

... und es zeigt schoen, warum es sinnvoll ist, Variablenexpansionen normalerweise zu doublequoten.

Richtig, es sei denn, man will es so. Und ich kann's öfters so gebrauchen.

Du kannst natuerlich tun was du willst. Meiner Erfahrung nach ist es ueblicherweise so, dass ein Quoten der Variablenexpansion in etwa 90% der Faelle das ist was man haben sollte. Falls man einmal zu viel quoted, dann ist der Fehler gleich offensichtlich. Falls man einmal zu wenig quoted, dann funktioniert es oft scheinbar gut, bis dann mal ein unerwarteter Wert kommt. Das sind aber nur Erfahrung und rationale Argumentation, du darfst es natuerlich auch anders machen. (Wer sehr genau weiss, was er tut, darf sich auch mal begruendet ueber die Best Practice hinwegsetzen ... was er aber aus gutem Grund selten wollen wird.)

[Lohengrin]

Gut erklärt, Meillo!
Bis auf eine Sache, die mich zum Schmunzeln gebracht hat.

4) Die Shell forked und ruft per exec() /bin/echo mit einem argv von vier Strings ("echo", "foo", "bar", "baz") auf.

Ich habe kein Problem damit, englische Begriffe einzudeutschen, wenn es denn im Zusammenhang sinnvoll ist. Aber dann muss man auch deutsch beugen. Ich forke, du forkst, die Shell forkt.

Obwohl ich inzwischen recht viel Erfahrung mit Bash habe, bringt mich das mit den Anführungszeichen manchmal noch ins Schleudern. Besonders tückisch finde ich das Auflösen von nacktem peng{seufz,schnauf}uff und das Auflösen von * ? [a-f] in nackten Ausdrücken. Je nachdem, was gerade im Verzeichnis zu finden ist, kann dabei Unerwartetes herauskommen, wobei da auch noch LC_COLLATE mitspielt.
Man muss erkennen, ob das Ding zu Parametern hinter einem Befehl wird, ob es etwas wird, das in eine Variable gesteckt wird, ob Integer-Arithmetik gilt oder ob Regex gilt.

Was ich noch nicht durchblickt habe, ist !. Das habe ich noch nie gebraucht. Es kommt mir nur bei echo -e "Text!\nMehr Text!" lästig in die Quere.

[RobertDebiannutzer]

Was ich noch nicht durchblickt habe, ist !. Das habe ich noch nie gebraucht. Es kommt mir nur bei echo -e "Text!\nMehr Text!" lästig in die Quere.

Dann mach' halt

Code: Alles auswählen

echo -e "Text! \nMehr Text!"

(einfach ein Leerzeichen zwischen "!" und "\n")

[owl102]

...oder

Code: Alles auswählen

echo -e 'Text!\nMehr Text!'

[Lohengrin]

...oder

Code: Alles auswählen

echo -e 'Text!\nMehr Text!'

oder

Code: Alles auswählen

echo -e "Text\x21\nMehr Text\x21"

Ist sowas wie \x22 für ", nur dass man es nicht mit \! wie \" maskieren kann.

[raa]

1) Die Shell liest eine Zeile:

Code: Alles auswählen

echo $irgendeinString

2) Die Shell expandiert die Variable:

Code: Alles auswählen

echo foo  bar    baz

3) Die Shell macht Word-Splitting:

Code: Alles auswählen

"echo" "foo"  "bar"    "baz"

4) Die Shell forked und ruft per exec() /bin/echo mit einem argv von vier Strings ("echo", "foo", "bar", "baz") auf.

5) echo(1) gibt jedes seiner Argumente Leerzeichen getrennt aus.

Klar, danke

Du kannst natuerlich tun was du willst. Meiner Erfahrung nach ist es ueblicherweise so, dass ein Quoten der Variablenexpansion in etwa 90% der Faelle das ist was man haben sollte. Falls man einmal zu viel quoted, dann ist der Fehler gleich offensichtlich. Falls man einmal zu wenig quoted, dann funktioniert es oft scheinbar gut, bis dann mal ein unerwarteter Wert kommt.

Auch klar. Ich mache das eben nur, wenn ich's genau so sehen will: Aus irgend einem String (einem reinen String, der keine zu expandierenden Variablen enthält), die "überflüssigen" Blanks enternen.

[Meillo]

Bis auf eine Sache, die mich zum Schmunzeln gebracht hat.

4) Die Shell forked und ruft per exec() /bin/echo mit einem argv von vier Strings ("echo", "foo", "bar", "baz") auf.

Ich habe kein Problem damit, englische Begriffe einzudeutschen, wenn es denn im Zusammenhang sinnvoll ist. Aber dann muss man auch deutsch beugen. Ich forke, du forkst, die Shell forkt.

Ja ... typisches Problem bei mir.

Was ich noch nicht durchblickt habe, ist !. Das habe ich noch nie gebraucht. Es kommt mir nur bei echo -e "Text!\nMehr Text!" lästig in die Quere.

Was ist denn `!'? History Expansion? Meine Shell macht das nicht. Im non-interaktiven Modus macht die Bash das auch nicht. Das finde ich manchmal irritierend, wenn sich die Shell unterschiedlich verhaelt, je nachdem ob man einen Befehl interaktiv oder in einem Script ausfuehrt.

[raa]

Das finde ich manchmal irritierend, wenn sich die Shell unterschiedlich verhaelt, je nachdem ob man einen Befehl interaktiv oder in einem Script ausfuehrt.

Wem sagst du das.

Bis auf eine Sache, die mich zum Schmunzeln gebracht hat.

4) Die Shell forked und ruft per exec() /bin/echo mit einem argv von vier Strings ("echo", "foo", "bar", "baz") auf.

Ich habe kein Problem damit, englische Begriffe einzudeutschen, wenn es denn im Zusammenhang sinnvoll ist. Aber dann muss man auch deutsch beugen. Ich forke, du forkst, die Shell forkt.

Ja ... typisches Problem bei mir.

So, dann habe ich ein Problem: Eins der wenigen englischen Wörter, die ich gerne verwende, weil sie kürzer, prägnanter oder / und "klangvoller" sind, ist "Amp" ("amplifier" - "Verstärker"). Also wie muss das dann heißen: Ich ampe, du ampst, der Amp ampt - oder wie ...

[Lohengrin]

So, dann habe ich ein Problem: Eins der wenigen englischen Wörter, die ich gerne verwende, weil sie kürzer, prägnanter oder / und "klangvoller" sind, ist "Amp" ("amplifier" - "Verstärker"). Also wie muss das dann heißen: Ich ampe, du ampst, der Amp ampt - oder wie ...

Ob Smiley oder nicht, ich antworte darauf.
Im Englischen ist die Trennung zwischen Kernwort und Dingwort fließend. Bei "Time flies like an arrow." kann jedes der nullten drei Wörter das Kernwort sein. Im Deutschen haben wir diese Flexibilität nicht.
"Amp" bedeutet für mich irgendwas von "amplum". Das könnte Verstärker sein. Wenn man daraus ein Kernwort macht, dann würde ich es tatsächlich gemäß ich ampe, du amps, das (nicht der) Amp ampt beugen. Aber ich verwende da lieber "der Verstärker verstärkt", gerne auch mit rammsteinscher Betonung.

Das Ansinnen, so viele Wörter wie möglich auf deutsch zu schreiben, ist mMn Quatsch, insb weil sehr viele deutsche Wörter ohnehin ausländischen Ursprung haben. Aber so einige Konstruktionen finde ich zum Schießen, wie zB Meuchelpuffer. Das ist noch viel besser als der berühmte Viertopfknalltreibling.
Aber wenn es schon treffende deutsche Wörter gibt, die auch noch sehr kurz sind, sehe ich es nicht ein, Englisches einzudeutschen. ZB heißt Downloaden bei mir holen, uploaden heißt bei mir bringen, und Motherboard heißt bei mir nicht Mutterbrett, sondern Hauptplatine.

[raa]

Naja, so hat eben jeder seine Ansichten. Ich finde nun so maches "neudenglische" schlichtweg schwachsinnig. Ein Saftladen bleibt ein Saftladen, auch wenn man ihn "juice shop" nennt. Und gugge mal hier: http://hkraus.eu - wie sagte Burke mal: "Auf 'Ich-bin-gut-drauf-und-gehe-heute-tanzen-Baby'-Geplänkel hat in meiner Band keiner Lust, das überlassen wir lieber der Kommerz-Musik, die eh' nichts anders macht. Für mich zählen die Gedanken, die sich ein Mensch oder eine Gruppe macht, bevor sie damit an die 'Öffentlichkeit' geht." Ich also. "He, du deutscher Rockmusiker, wieso macht ihr euch dann eure Gedanken erst auf deutsch und übersetzt sie dann ins Englische? Ich verstehe kein Wort." Oh, da hatte ich aber eine Diskussion ausgelöst ...