Macro in Bash

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Macro in Bash

Beitrag von RobertDebiannutzer » 21.11.2018 09:52:04

Was man vielleicht bezüglich bash vs. dash noch erwähnen könnte, ist, dass dash schneller sein kann. Also je nach Aufgabe natürlich. Das kann auch mal ganz nützlich sein. Also wenn man jetzt immer mal wieder ein kleines Mini-Script für irgendwas startet, dann würde ich das eher für dash schreiben.
Für etwas, was mehr "sophisticated" ist, immer bash.
Was auch bei Funktionen in bash toll ist, ist, dass sie Argumente annehmen können.

BTW: Den Rekord des schlimmsten Shell-Scripts aller Zeiten beanspruche eh ich...
Mal ein Auszug aus einem ganz schlimmen Script, das ich früher mal schrieb:

Code: Alles auswählen

[...]
for ((q=1; q<=4; q++)); do
	if (( q == 1 )); then
		TEST
		tput cup $(($(($((q-1))*2*QUANT+1+q-y))*x)) 0
		for ((l=1; l<=QUANT; l++)); do
			echo $(echo -e "${NUM[$l]}\n" &)
		done
		for ((l=2; l<=QUANT; l++)); do
			if (( l <= 3 )); then
				for ((i=$((l-1)); i>=$((l-$((l-1)))); i--)); do
					TEST
					tput cup $(($(($((l*2-1-$((l-i))))+$((q-1))*2*QUANT+q-y))*x)) $(($((l-i))*$((2+QUANTC))))
					echo $(echo "${NUM[$l]}-${NUM[$i]}" | bc &)
				done
			else
				for ((i=$((l-1)); i>=$((l-3)); i--)); do
					TEST
					tput cup $(($(($((l*2-1-$((l-i))))+$((q-1))*2*QUANT+q-y))*x)) $(($((l-i))*$((2+QUANTC))))
					echo $(echo "${NUM[$l]}-${NUM[$i]}" | bc &)
				done
			fi
		done
	elif (( q == 2 )); then
[...]
oder das:

Code: Alles auswählen

[...]
countalign3=$(($(printf "%s\n" ${zielspalte[@]} | wc -L)+1))
if (( countalign2 <= countalign3 )); then countalignmax=$countalign3; else countalignmax=$countalign2; fi

for ((l=1; l<=count; l++)); do
	for ((i=1; i<=indent; i++)); do printf "%s" " "; done
	printf "%s" "| " && printf "%s\n" ${line2[l]} | while read number; do printf %"$countalignmax"s "$number"; done
	if (( l == 1 )); then printf "%s" "    (2. Matrix)"; fi
	printf "\n"
done

count3=$((countalignmax*$(wc -w <<< ${line2[1]})+countalign*count+5))
for ((i=1; i<=count3; i++)); do printf "%s" "–"; done && printf "\n"

for ((l=1; l<=lines; l++)); do
	printf "%s\n" ${line[l]} | while read number; do printf %"$countalign"s "$number"; done && printf "%s" "  | "
	printf "%s\n" ${zielzeile[l]} | while read number; do printf %"$countalign3"s "$number"; done
	if (( l == 1)); then printf "%s\n" "    (Ergebnis)"; else printf "\n"; fi
done
printf "\n"
(Das eine war der Versuch eines Scriptes zum Lösen von diesen dusseligen Zahlenreihen - also z.B. "was ist das Muster in '1 3 2 6 3 9'?" -, das andere war ein Script zur Matrizenmultiplikation...)

Benutzeravatar
Meillo
Moderator
Beiträge: 8818
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Macro in Bash

Beitrag von Meillo » 21.11.2018 11:27:00

owl102 hat geschrieben: ↑ zum Beitrag ↑
20.11.2018 18:53:02
Es ist doch ganz einfach:

- Benötigt man keine Kompatiblität zu anderen Shells außer der bash, ist es sinnvoll, bash-Skripte zu schreiben, die Features der bash nutzen. Sie machen den Code einfacher, lesbarer, robuster und wartbarer.
Man kann das so sehen oder anders. Ich finde, das ist wie mit C und C++, manchmal ist zweiteres besser (im Sinne von einfacher, lesbarer, robuster, wartbarer), aber nicht immer. Manchmal laesst sich das objektiv feststellen, manches haengt mehr an persoenlichen Erwartungen, Vorlieben, Prioritaeten.

Aber ja: Wenn man keine Kompatiblitaet braucht, dann kann man verwenden, was einem selbst am sinnvollsten erscheint. So gesehen stimme ich dir zu.
- Benötigt man Kompatiblität zu anderen Shells außer der bash, ist es sinnvoll, POSIX-Scripte zu schreiben.

Egal wie man sich entscheidet, auf beiden Seiten gewinnt man etwas und verliert etwas. Eine Entscheidung muß daher IMHO individuell gefällt werden.
Ja.

Im Falle des POSIX-Standards hat man sogar noch ein weiteres Problem: Der POSIX-Standard ist an vielen Stellen schwammig. Selbst wenn man "#!/bin/sh" schreibt und keine Bashisms verwendet, kann es sehr gut sein, daß das Skript in einer anderen Umgebung/Shell nicht wie erwartet funktioniert. Beispiel "echo": Es ist lediglich spezifiziert, daß es Zeichenketten + Zeichenumbruch ausgibt. Verhalten bei Sequenzen mit Backslash am Anfang, wie z.B. "\t"? AFAIK nicht durch POSIX gedeckt, kann so oder so sein. [1] Schalter "-n" vorhanden? AFAIK nicht durch POSIX gedeckt. (Deswegen hier am besten immer printf statt echo verwenden.) Wird bei "xxx | ... <Schleife>" intern eine Subshell gestartet oder nicht, d.h. sind dort gesetzte Variablen auch am Ende der Schleife noch vorhanden? Nach meinem Kenntnisstand läßt POSIX dies offen, d.h. das kann jede Shell so machen wie sie mag. [2] Und so weiter... Bei bash hingegen hat man nur bei anderen Versionen der bash ggf. ein anderes Verhalten, und diese Dinge sind sowohl übersichtlich als auch konkret dokumentiert.

Und dann ist POSIX auch nicht gleich POSIX, auch hier gibt es unterschiedliche Versionen des Standards. Wenn man sich für POSIX entscheidet, welche Version des Standards nimmt man?
Als Ergaenzung: Man muss POSIX korrekt verstehen. Sein Ziel war, ausgehend von den Zeiten der sogenannten Unix-Kriege, die Gemeinsamkeiten der verschiedenen Unix-Systeme zu dokumentieren. Es ging bei POSIX also nicht darum, Verhalten zu *definieren*, sondern darum Verhalten zu *dokumentieren*. Insofern unterscheidet sich POSIX von anderen Standards. Nicht definiertes Verhalten ist bei POSIX kein Fehler sondern eine Notwendigkeit. Aus diesen Gruenden kann POSIX manches schlichtweg nicht leisten, was manchmal von ihm erwartet wird.

POSIX hilft dabei, groessere Portabilitaet zu erreichen, aber es kann ueberhaupt nichts garantieren. (Viele sich als POSIX-kompatibel bezeichnenden Programme sind ueberhaupt nicht vollstaendig POSIX-kompatibel.)

Wenn man garantierte Kompatibilitaet haben will, dann muss man gegen eine bestimmte Version einer bestimmten Shell mit bestimmten Build-Parametern entwickeln und diese Shell dann als Abhaengigkeit voraussetzen.

Es kommt also immer darauf an, wie man die Dinge betrachtet. Diese etwas andere Perspektive auf die durchaus korrekten Aussagen wollte ich ergaenzen.
Use ed once in a while!

owl102

Re: Macro in Bash

Beitrag von owl102 » 21.11.2018 18:40:55

Meillo hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 11:27:00
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

raa
Beiträge: 411
Registriert: 19.12.2013 10:16:19

Re: Macro in Bash

Beitrag von raa » 21.11.2018 22:09:19

Lohengrin hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 01:18:24
raa hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 00:42:37
Irgendwann hab' ich also mal angefangen, die kryptischen Befehle (die ich mir nie im Leben merken kann und will), als Funktionen in private "Libraries" zu verpacken. Es ist wohl ein Unterschied, ob man jedesmal sowas konstruieren muss:

Code: Alles auswählen

echo "$str" | sed -e "s/"$strLeftMarg"[^<>]*"$strRightMarg"/"$strSub"/g; /^[ ]*$/d" 
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:

Code: Alles auswählen

# Achtung: Punkte in "$strPartRep" maskieren: '\\.', sonst werden sie als Platzhalter interpretiert
# Option: Steuerzeichen, das im String nicht vorkommt (default: '/')
Na, und so weiter ... :wink:
Lohengrin hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 01:18:24
Ansonsten richtig so! Jedenfalls in der Theorie.
Wenn ich zwei mal das gleiche Kompliziertere brauche, ist es Zeit für eine Funktion. Dann hat man (so wie jetzt du) nämlich mögliche Fehler an derselben Stelle. Nur wenn ich die beiden zurechtbiegen muss, damit sie dieselbe Funktion benutzen können, kann es sein, dass die Biegerei aufwendiger ist als der Vorteil durch die Funktion.
Dann muss man also die Funktion "zurechtbiegen", s.o.

Benutzeravatar
Lohengrin
Beiträge: 3227
Registriert: 29.08.2004 00:01:05
Wohnort: Montsalvat

Re: Macro in Bash

Beitrag von Lohengrin » 21.11.2018 23:13:53

raa hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 22:09:19
Lohengrin hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 01:18:24
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"
}
raa hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 22:09:19

Code: Alles auswählen

# Achtung: Punkte in "$strPartRep" maskieren: '\\.', sonst werden sie als Platzhalter interpretiert
# Option: Steuerzeichen, das im String nicht vorkommt (default: '/')
Du kannst auch die Variablen, bevor sie ins Monster gesetzt werden, bearbeiten

Code: Alles auswählen

local a b c
a=$(echo -n "$2" | sed 's/\//\\\//g; s/\./\\\./g' )
b=$(echo -n "$3" | sed 's/\//\\\//g; s/\./\\\./g' )
c=$(echo -n "$4" | sed 's/\//\\\//g; s/\./\\\./g' )
echo "$1" | sed -e "s/$a[^<>]*$b/$c/g; /^[ ]*$/d"
Wobei du dann natürlich wieder eine Funktion für die drei gleichen Zeilen machen könntest.
Harry, hol schon mal das Rasiermesser!

owl102

Re: Macro in Bash

Beitrag von owl102 » 21.11.2018 23:25:59

Lohengrin hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 23:13:53

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.

Benutzeravatar
Lohengrin
Beiträge: 3227
Registriert: 29.08.2004 00:01:05
Wohnort: Montsalvat

Re: Macro in Bash

Beitrag von Lohengrin » 21.11.2018 23:33:52

owl102 hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 23:25:59
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.
owl102 hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 23:25:59
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.
Harry, hol schon mal das Rasiermesser!

raa
Beiträge: 411
Registriert: 19.12.2013 10:16:19

Re: Macro in Bash

Beitrag von raa » 22.11.2018 08:51:46

Lohengrin hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 23:13:53
raa hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 22:09:19
Lohengrin hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 01:18:24
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. :wink: 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. :wink:

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

Code: Alles auswählen

#!/bin/bash
;)

Benutzeravatar
Meillo
Moderator
Beiträge: 8818
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Macro in Bash

Beitrag von Meillo » 22.11.2018 09:32:47

owl102 hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 18:40:55
Meillo hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 11:27:00
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. :-)
Use ed once in a while!

Benutzeravatar
Meillo
Moderator
Beiträge: 8818
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Macro in Bash

Beitrag von Meillo » 22.11.2018 09:34:04

raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 08:51:46
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? ;-)
Use ed once in a while!

raa
Beiträge: 411
Registriert: 19.12.2013 10:16:19

Re: Macro in Bash

Beitrag von raa » 22.11.2018 09:57:54

Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 09:34:04
raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 08:51:46
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
Beiträge: 411
Registriert: 19.12.2013 10:16:19

Re: Macro in Bash

Beitrag von raa » 22.11.2018 10:11:26

owl102 hat geschrieben: ↑ zum Beitrag ↑
21.11.2018 23:25:59
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. :wink: 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

Re: Macro in Bash

Beitrag von owl102 » 22.11.2018 10:16:33

raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 09:57:54
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

Benutzeravatar
Meillo
Moderator
Beiträge: 8818
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Macro in Bash

Beitrag von Meillo » 22.11.2018 10:22:39

raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:11:26

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.
Use ed once in a while!

raa
Beiträge: 411
Registriert: 19.12.2013 10:16:19

Re: Macro in Bash

Beitrag von raa » 22.11.2018 12:35:07

owl102 hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:16:33
raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 09:57:54
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
Beiträge: 411
Registriert: 19.12.2013 10:16:19

Re: Macro in Bash

Beitrag von raa » 22.11.2018 12:39:43

Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:22:39
raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:11:26

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. ;)
Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:22:39
... 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
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Macro in Bash

Beitrag von RobertDebiannutzer » 22.11.2018 12:58:25

Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:22:39
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

Re: Macro in Bash

Beitrag von owl102 » 22.11.2018 14:24:03

raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 12:35:07
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

Benutzeravatar
Meillo
Moderator
Beiträge: 8818
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Macro in Bash

Beitrag von Meillo » 22.11.2018 16:58:47

raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 12:39:43
Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:22:39
raa hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:11:26

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.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html hat geschrieben: 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.

Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 10:22:39
... 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.)
Use ed once in a while!

Benutzeravatar
Lohengrin
Beiträge: 3227
Registriert: 29.08.2004 00:01:05
Wohnort: Montsalvat

Re: Macro in Bash

Beitrag von Lohengrin » 23.11.2018 06:12:30

Gut erklärt, Meillo!
Bis auf eine Sache, die mich zum Schmunzeln gebracht hat.
Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 16:58:47
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.
Harry, hol schon mal das Rasiermesser!

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: Macro in Bash

Beitrag von RobertDebiannutzer » 23.11.2018 09:48:13

Lohengrin hat geschrieben: ↑ zum Beitrag ↑
23.11.2018 06:12:30
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

Re: Macro in Bash

Beitrag von owl102 » 23.11.2018 10:08:54

...oder

Code: Alles auswählen

echo -e 'Text!\nMehr Text!'

Benutzeravatar
Lohengrin
Beiträge: 3227
Registriert: 29.08.2004 00:01:05
Wohnort: Montsalvat

Re: Macro in Bash

Beitrag von Lohengrin » 23.11.2018 10:30:13

owl102 hat geschrieben: ↑ zum Beitrag ↑
23.11.2018 10:08:54
...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.
Harry, hol schon mal das Rasiermesser!

raa
Beiträge: 411
Registriert: 19.12.2013 10:16:19

Re: Macro in Bash

Beitrag von raa » 23.11.2018 10:40:38

Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 16:58:47
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
Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 16:58:47
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.

Benutzeravatar
Meillo
Moderator
Beiträge: 8818
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Macro in Bash

Beitrag von Meillo » 23.11.2018 13:04:45

Lohengrin hat geschrieben: ↑ zum Beitrag ↑
23.11.2018 06:12:30
Bis auf eine Sache, die mich zum Schmunzeln gebracht hat.
Meillo hat geschrieben: ↑ zum Beitrag ↑
22.11.2018 16:58:47
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. :roll:

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.
Use ed once in a while!

Antworten