staging.inyokaproject.org

Kann das halt schlecht abschätzen im Moment. Für ein paar Postings im S&P reicht’s bei mir, aber der Artikel da ist echt lang. Den sinnvoll zu pflegen erfordert schon signifikant Zeit, Sorgfalt und Motivation.

Das „Ich“ hab’ ich jetzt mal noch entfernt (und zwei fehlende Kommas gesetzt).

Hallo!

Ich bin dabei mich in die Bash einzuarbeiten und finde diesen "Guide für Anfänger" richtig klasse. Super strukturiert und kurzweilig - besser als alle Bash-Artikel die ich dafür bis jetzt angesehen habe.

Mittlerweile bin ich hier angekommen: Bash-Skripting-Guide für Anfänger (Abschnitt „Schleifen“) und habe Probleme mit folgendem Skript, welches meiner Meinung nach so nicht funktionieren kann:

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

#!/bin/bash

#Variablendefinition

inputdir="/home/foo/Bilder/ZuBearbeiten/"

outputdir="/home/foo/Bilder/Bearbeitet/"

#Abarbeiten der eingelesenen Bilder mit Hilfe einer For-Schleife
#und dem Tool ImageMagick.

for pic in "$inputdir" ; do 
    picname=$( basename "$pic")
    echo "Bearbeite Bild:    $picname"
    echo "-------------------------------------------0"
    convert "$pic" -colorspace Gray "$outputdir$picname"
done

An die Variable "inputdir" wird doch wirklich nur der Name des Pfades übergeben und nicht dessen Inhalt, der dann in Listenform für die for-Schleife nötig ist? Generell kann doch eine einfache Variable keine Liste aufnehmen, dazu bräuchte man dann ein Array, oder?

Ich habe ein bisschen herumexperimentiert und meine, dass die Schleife wenn, dann nur so aussehen kann:

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

#!/bin/bash

#Variablendefinition

inputdir="/home/foo/Bilder/ZuBearbeiten/"

outputdir="/home/foo/Bilder/Bearbeitet/"

#Abarbeiten der eingelesenen Bilder mit Hilfe einer For-Schleife
#und dem Tool ImageMagick.

for pic in $( ls $inputdir ) ; do 
    picname=$( basename "$pic")
    echo "Bearbeite Bild:    $picname"
    echo "-------------------------------------------0"
    convert "$inputdir$pic" -colorspace Gray "$outputdir$picname"
done

Auch wenn hier immernoch das Problem besteht, dass die Bilddateinamen keine Leerzeichen enthalten dürfen. Wisst ihr wie auch das sicherzustellen wäre?

Seht ihr das auch so?

Bash-Skripting macht echt voll viel Spaß 😎

P.S.:Übrigens ist leider der Buch-Tipp-Link am Ende der Seite nicht mehr verfügbar.

ls zu verwenden ist eine ganz schlechte Idee, und Du hast auch schon erkannt wieso.

1

for pic in "$inputdir"/*.png ; do      picname=$( basename "$pic");     echo "Bearbeite Bild:    $picname"; done

Noch nicht erkannt wurde, wieso hier:

1

inputdir="/home/foo/Bilder/ZuBearbeiten/"

der abschließende Slash fehl am Platz ist.

Ist die Überarbeitung eigentlich fertig?

Aus aktuellem Anlaß habe ich noch einen Haufen Änderungen vorgenommen:

type Skriptname 

Damit ein Skript ohne Angabe des Interpreters ausgeführt werden kann, muss es zuerst ausführbar gemacht werden. Dies geschieht z.B. in der Konsole durch folgenden Befehl.

Hier stand zuvor 'which', welches buildins nicht findet, und auch Schlüsselwörter wie 'for' nicht. Durch type ersetzt.

Es sollte aber (insbesondere bei von mehreren Personen benutzten Rechnern und Servern) darauf geachtet werden, dass Skripte, die in globalen Verzeichnissen (wie /usr/bin/) abgelegt werden, dem Benutzer root gehören und nur dieser in die Datei schreiben darf, ansonsten öffnet man eine Sicherheitslücke.

Worin besteht die Sicherheitslücke? Dass ich ein Script "pony.sh" da ablege, welches "wieher, wieher" ausgibt, wenn aufgerufen, und weil das allen soviel Spaß macht, nutzt es jeder, und wenn das Misstrauen gebrochen ist, dann ändere ich den Inhalt des Skriptes derart, dass es / rekursiv löscht?

Natürlich ist es möglich, bei jedem Aufruf seines Skriptes die ausführende Shell von Hand festzulegen, doch diesen Aufwand möchte man nicht wirklich treiben. Die übliche Vorgehensweise ist, dies direkt im Skript anzugeben. Dies wird durch die Shebang ermöglicht, welche die erste Zeile eines Skriptes darstellt.

a) 'nicht wirklich treiben' ist so eine Floskel, die man in einem Wiki nicht wirklich lesen will. Durch 'nicht oft' ersetzt. b) Der Shebang ist männlich - oder?

Ein Bash-Skript darf also niemals /bin/sh als Shebang verwenden – dies funktioniert lediglich in Ausnahmefällen.

Eine offensichtliche contradictio in adjecto - ein Widerspruch in sich. Wenn es in Ausnahmefällen funktioniert, dann ist 'niemals' falsch, oder man darf es niemals verwenden.

Einfach mal

1

grep '#!/bin' /etc/init.d/*

ausführen, und überlegen, wie oft man schon derartige Scripte im Rahmen der Bash ausgeführt hat. Geänert in:

Ein Bash-Skript, dass /bin/sh als Shebang verwendet funktioniert lediglich in Ausnahmefällen.

var="hallo" 

In diesem Beispiel wird der Variablen mit dem Namen var der Wert hallo zugewiesen. Hierbei sollte man darauf achten, die Zuweisung in Anführungszeichen zu setzen. Dies ist genau genommen jedoch nur notwendig, wenn die Zuweisung Leerzeichen oder andere Sonderzeichen enthält.

Was soll hier "genau genommen" heißen? Und "jedoch"? Und "nur"? Ist es notwendig oder nicht? Deine Rede sei "Ja, Ja!" oder "Nein, nein" - alles dazwischen ist von übel!

Räumt man das sprachliche Gerümpel beiseite, und versucht nicht eine Behauptung aufzustellen, die unwahr ist, dann wird der Satz kurz und klar:

Wenn die Zuweisung Leerzeichen oder andere Sonderzeichen enthält, sind Anführungszeichen notwendig:

Ähnliches Gerümpel finde ich auch hier vor, bin aber unfähig es zu verbessern, weil ich nicht erst verstehe, was überhaupt gemeint ist:

Prinzipiell wird ein Skript nur indirekt über seinen Interpreter gestartet.

Wenn ich die Undeutlichkeiten weglasse steht da "Ein Skript wird über seinen Interpreter gestartet." was einleuchtend ist, und dem Anfänger ruhig gesagt werden soll (Es folgt dann eine Betrachtung der Prozesse - neuer Prozess oder nicht). Aber was sollen die "nur indirekt" und "Prinzipiell"? Heißt das "immer" oder "bis auf Ausnahmen"?

Gelegentlich kann es der Fall sein, dass man Variablen innerhalb eines Strings verwenden möchte. Dabei kommt es zu Schwierigkeiten, da die Konsole dann die Variable nicht mehr von dem sie umgebenden String unterscheiden kann. Um dieses Problem zu umgehen, verwendet man eine Schreibweise mit geschweiften Klammern. Ein Beispiel zeigt das Problem.

echo "$var" 

hallo

echo "$varlolo" 

Hier wird nach dem Anhängen eines beliebigen Strings an die Variable $var eine leere Variable ausgegeben. Dies liegt daran, dass die Bash versucht, die Variable mit dem Namen $varlolo auszugeben, welche nicht belegt und daher eben leer ist. Grenzt man die Variable jedoch durch die Schreibweise mit geschweiften Klammern ab, bekommt man folgendes Ergebnis.

echo "${var}lolo" 

hallololo

Nachdem oben mehr oder weniger dogmatisch versucht wurde, ein Quoting für Strings für die Bash einzufordern wird jetzt darauf aufbauend ${foo}lala gezeigt. Wenn man aber nicht an das Quoting glaubt, dann kann man natürlich auch

1

echo $foo"lala" 

schreiben. Nicht, dass es besser wäre als

1

echo ${foo}lala

oder

1

echo "${foo}lala"

oder gar:

1

echo "$foo"lala 

Ist aber nicht so wichtig - immerhin wird ja nichts falsches behauptet.

Hier ist aber ein Punkt erreicht, wo man es sich unnötig schwer macht:

echo 'So sprach'"'"'s und ging ohne einen Backslash (\) weiter.' 

weswegen ich auf die einfachere Lösung aufmerksam mache:

echo So sprach"'"s und ging ohne einen Backslash '(\)' weiter. 

Arrays werden auch als Feldvariablen bezeichnet. Sie ermöglichen es, mehrere Werte gleicher Art innerhalb einer Variable abzuspeichern. Die einzelnen Werte stehen dabei in Feldern des Arrays und können über den Index des Feldes einzeln angesprochen werden. Arrays lassen sich hervorragend über Schleifen verarbeiten, was etwas weiter unten noch beschrieben wird.

gleicher Art stimmt nicht.

1

arr=(1 "foo" "foo bar" $(date) "$(date)" "\$(date)" ~/Desktop/*.png)

Echo kann man verwenden um den Benutzer des Skriptes wissen zu lassen was gerade passiert, oder um ihn aufzufordern eine Eingabe zu machen. Hierbei sollte man darauf achten, den auszugebenden Text in Anführungszeichen zu setzen.

Aha. Und wozu soll man den Text in Anführungszeichen setzen? Weil man das in Python auch macht?

Beim Einlesen von Variablen verwendet man aber ohnehin read -p

1

reap -p "Dat is hier ein Prompt!" something

und so habe ich das auch ca. 4x ersetzt.

So nach 2/3 habe ich dann die Lust verloren weiter Erbsen zu zählen. ☺

Sollte ein Hinweis rein, das man mit der bash keine Kommazahlen berechnen kann? Oder kann man?

So nach 2/3 habe ich dann die Lust verloren weiter Erbsen zu zählen.

Och komm, das letzte Drittel schaffst Du auch noch ☺

Gruß
kaputtnik

kaputtnik schrieb:

So nach 2/3 habe ich dann die Lust verloren weiter Erbsen zu zählen.

Och komm, das letzte Drittel schaffst Du auch noch ☺

Vielleicht wenn Du hilfst? Was, z.B., ist ein programmführendes Konstrukt?

Das Test-Kommando¶

Das Test-Kommando wird dazu benötigt auf diverse Bedingungen hin zu testen. Es wird oft in Zusammenhang mit programmführenden Konstrukten verwendet.

Was es nicht alles gibt! ☺

! foo

Ist wahr wenn foo falsch ist, also eine Negation.

Hier stand 'String' statt 'foo', was m.E. falsch ist.

(Kleinigkeiten, siehe Wiki-diff)

Mit Hilfe des Befehls shift kann das Skript auf mehr als neun Parameter zugreifen. Shift verschiebt dabei alle Parameter, die auf der Kommandozeile übergeben wurden, eine Position nach links. In dem kurzen Beispiel werden kurzschließende Tests durchgeführt, die im Prinzip wie if arbeiten.

1 2 3 4 5 6 7 8

#!/bin/bash while [ $1 != '' ] do [ $1 == "-b" ] && BACKUP="yes" && echo "Ok. Mache ein Backup" && shift [ $1 == "-r" ] && RESTORE="yes" && echo "Ok. Mache ein Restore" && shift [ $1 == "-c" ] && CLEAN="yes" && echo "Ok. Räume auf" && shift done

Begeistert mich nicht restlos, denn man könnte es falsch auffassen, dass shift nur für Situationen mit mehr Parametern gedacht ist, wenn man das Beispiel nicht liest - andererseits schließt der Text so an den vorigen Absatz mit $1 bis $9 an.

Aber ein Beispiel, bei dem backup + restore unmittelbar nacheinander gemacht werden, in ungewisser Folge? Hat jemand vielleicht realen Code mit einem Shift? Würde man dieses Problem hier nicht eher mit einem case lösen?

Funktionen¶

Funktionen helfen die Übersichtlichkeit zu verbessern, sie können mehrere Befehle zu logischen Gruppen zusammenfassen. Wurden sie einmal definiert, können sie im Skript durch ihren Namen aufgerufen werden. Wichtig ist, dass die Definition der Funktion vor ihrem ersten Aufruf stattgefunden haben muss. Es ist also ratsam, zunächst die Funktionen zu definieren und diese später, im Hauptteil des Skripts, aufzurufen. Durch diese Vorgehensweise bleibt das Skript logisch und übersichtlich. Im Allgemeinen sieht eine Funktion folgendermaßen aus.

Was soll das sein - eine logische Gruppe? {And, And, Not und Or}? Zu semantischen Gruppen soll zusammengefasst werden.

"im Hauptteil des Skriptes" ist insofern falsch, als man aus Funktionen Funktionen aufrufen kann und soll.

Funktionen helfen die Übersichtlichkeit zu verbessern, sie können mehrere Befehle zu semantischen Gruppen zusammenfassen. Wurden sie einmal definiert, können sie im Skript durch ihren Namen aufgerufen werden. Wichtig ist, dass die Definition der Funktion vor ihrem ersten Aufruf stattgefunden haben muss. Es ist also ratsam, zunächst die Funktionen zu definieren:

Ab dialog habe ich aus Mangel an Erfahrung nichts mehr modifiziert, nur in der Einleitung die Behauptung, dadurch würden Programme aufgewertet, hinauskomplimentiert.

Ein paar Screenshots von den besprochenen Elementen wären da nicht schlecht - nur als kl. Auswahl, 3 oder 4 nebeneinander., oder?

Das Wiki beschwert sich über Konfliktmarkierungen. Dabei gerät es mit mir wirklich in Konflikt - sollte da nicht ein Unterschied dann sichtbar sein? Ich sehe nichts!

Konflikt – vorherige Version

Das Test-Kommando wird dazu benötigt auf diverse Bedingungen hin zu testen. Es wird oft in Zusammenhang mit programmführenden Konstrukten verwendet. Test kennt verschiedene Operatoren welche die Bedingungen des Testes beeinflussen. In der Folgenden Tabelle sind die Möglichkeiten von Test gelistet.

Konflikt – eigene Version

Das Test-Kommando wird dazu benötigt auf diverse Bedingungen hin zu testen. Es wird oft in Zusammenhang mit programmführenden Konstrukten verwendet. Test kennt verschiedene Operatoren welche die Bedingungen des Testes beeinflussen. In der Folgenden Tabelle sind die Möglichkeiten von Test gelistet.

Konlikt Ende

Da sind ja rund 50 solcher scheinbarer Konflikte. Scheint ein derber Bug zu sein.

user unknown schrieb:

Das Wiki beschwert sich über Konfliktmarkierungen. Dabei gerät es mit mir wirklich in Konflikt - sollte da nicht ein Unterschied dann sichtbar sein? Ich sehe nichts!

Keine Ahnung... vllt zwei Browsertabs mit dem Artikel zum Beabeiten aufgehabt? Mir ist so etwas noch nicht passiert.

Zu shift: IMHO wäre es sinniger wenn man das ohne konkretes Anwendungsbeispiel erklären würde. Also eher so etwas wie

befehl param1 param2 param3 [...] param25 

Es soll ja erklärt werden, was das shift bewirkt. Das bisherige Beispiel wirft aus meiner Sicht mehr fragen auf als es Antworten gibt. Insebsondere weil dort so viele && zu finden sind... 😕

Gruß
kaputtnik

Praktische Beispiele, wo man das sieht, in welchen Fällen sowas hilfreich sein kann, finde ich schon wünschenswert - am besten eines, welches sich mit anderen Lösungsansätzen lange nicht so elegant lösen ließe.

Ich habe hier nur das experimentelle Sleepsort-Programm; man übergibt ein paar Ganzzahlen, und die werden alle in eine Funktion geschickt, die parallel ausgeführt wird, und die Zahl erst nach einer Wartezeit, die der Zahl entspricht, ausgegeben.

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

#!/bin/bash
#
function f() {
    sleep "$1"
    echo "$1"
}
while [ -n "$1" ]
do
    f "$1" &
    shift
done
wait

Beispiel:

1

sleepSort.sh 4 2 1 7 3

Es wartet also 4 Sekunden, bevor es 4 ausgibt, 2 bevor es 2 ausgibt usw. und gibt so, wenn nichts dazwischen kommt, und die Zeit, all die Prozesse zu starten nicht größer wird als 1s, die Zahlen am Ende in richtiger Reihenfolge aus.

Richtig überzeugt bin ich von dem Beispiel aber auch nicht.

user unknown schrieb:

Praktische Beispiele, wo man das sieht, in welchen Fällen sowas hilfreich sein kann, finde ich schon wünschenswert - am besten eines, welches sich mit anderen Lösungsansätzen lange nicht so elegant lösen ließe.

Praktische Beispiele findet man bestimmt jede Menge, nur meistens nicht die, die man für seinen Fall sucht. Mir geht das zumindest meistens so 😀 Ein Zeichen dafür, das man entweder das falsche sucht, oder man die verschiedenen Kontroll- bzw Steuerstrukturen nicht verstanden hat. 😉

Eleganz, oder „gutes” Programmieren, liegt sicherlich teilweise im Auge des Betrachters (so lange keine Geschwindigkeitsrelevanten Dinge dabei eine Rolle spielen).

Ich habe hier nur das experimentelle Sleepsort-Programm;

Jo, bis auf die Funktion f nicht verkehrt. Zeigt zumindest, was shift macht.

Ich fände so etwas nicht verkehrt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/bin/bash
array=""
paramnr=0
while [ -n "$1" ]
do
  echo "Parameter: $paramnr; Parameter: \"$1\""
  array+=($1)
  shift
  let paramnr+=1
done
echo "Alle Arraylemente:" ${array[*]}

Das zeigt auch was es macht. Die echo-Zeile in der Schleife und alle relevanten Zeilen die die Variable paramnr beinhalten kann man noch raus nehmen.

Oder ist das Mist?
kaputtnik

Ist doch alles etwas kompliziert ...

Was haltet Ihr von diesem Klassiker:

#!/bin/bash

until [ $# = 0 ] ; do
	echo "Gib mir ein  $1"
	wort="$wort$1"

	shift
	sleep 1
done

echo "$wort !"

z.B. mit dem Aufruf ./test_shift T o o r ...?

track

kaputtnik schrieb:

Eleganz, oder „gutes” Programmieren, liegt sicherlich teilweise im Auge des Betrachters (so lange keine Geschwindigkeitsrelevanten Dinge dabei eine Rolle spielen).

Nein. Eleganz zeigt sich darin, dass sie Dich gegen Deinen Willen umhaut.

Ich habe hier nur das experimentelle Sleepsort-Programm;

Jo, bis auf die Funktion f nicht verkehrt. Zeigt zumindest, was shift macht.

Oh ja, das würde man 'echo_delay ' oder so ähnlich nennen.

Ich fände so etwas nicht verkehrt:

1 2 3 4 5 6 7 8 9 10 11

#!/bin/bash array="" paramnr=0 while [ -n "$1" ] do echo "Parameter: $paramnr; Parameter: \"$1\"" array+=($1) shift let paramnr+=1 done echo "Alle Arraylemente:" ${array[*]}

Ich schon. Erstens zeigt es, wie man auf die Parameter ohne Index zugreift, und benutzt dann doch einen Index, wenn auch um die Parameter in das Array zu stecken – ach nein, nichtmals dafür! ☺ – Du siehst wie verwirrend das Beispiel ist!

Aber ich kenne hier auch eine elegantere Methode, die Dich hoffentlich umhaut ☺

1
2

array=($*)
echo "Alle Arraylemente:" ${array[*]}

Das zeigt auch was es macht. Die echo-Zeile in der Schleife und alle relevanten Zeilen die die Variable paramnr beinhalten kann man noch raus nehmen.

Das wäre sicher eine deutliche Verbesserung, und hätte mich nicht auf die falsche Fährte gesetzt bzgl. Index.

Oder ist das Mist?

Ich muss das sehen - da fehlt mir die Phantasie:

1
2
3
4
5
6
7
8

#!/bin/bash
array=""
while [ -n "$1" ]
do
  array+=($1)
  shift
done
echo "Alle Arraylemente:" ${array[*]}

Besser, aber gemessen an der alternativen Lösungsmöglichkeit, die m.E. unbestreitbar eleganter ist, schon. ☺

track schrieb:

Ist doch alles etwas kompliziert ...

Was haltet Ihr von diesem Klassiker:

#!/bin/bash

until [ $# = 0 ] ; do
	echo "Gib mir ein $1"
	wort="$wort$1"
	shift
	sleep 1
done

echo "$wort!"

z.B. mit dem Aufruf ./test_shift T o o r ...?

Gar nichts! 😉 Until war noch nicht.

Als Anwender könnte ich mir noch den Wunsch vorstellen, dass ich "Tooor" eingebe, und das Programm zerhackstückelt das Wort entsprechend. Gut - das wäre ja realisierbar, wenn das Programm zur Funktion würde, und man mit regulären Ausdrücken den Input zerstückelt - das müsste man aber auch erklären. Schön kurz ist es ja.

Ist das wirklich ein Klassiker? Das habe ich noch in keinem Buch und nirgends gesehen!

user unknown schrieb:

1 2	array=($*) echo "Alle Arraylemente:" ${array[*]}

Ok, das ist eleganz ☺

Nach längerem Überlegen bin ich gestern Abend im Bett zu dem Schluss gekommen, das diese shift-Geschichte in dieser Art doof ist. Wer mehr als 9 Parameter (darum gings ja) an ein Skript übergeben will, der weiß spätestens nach dem dritten Parameter nicht mehr, wofür der nächste eigentlich noch mal da war. Es sei denn, mit allen Parametern macht man das gleiche:

1
2
3
4
5
6
7
8
9

#!/bin/bash
#Addition
ergebnis=0
while [ -n "$1" ]
do
  ergebnis=$(( $ergebnis+$1 ))
  shift
done
echo "Ergebnis der addition: $ergebnis"

Wie oft kommt es vor, das mit allen Parametern das Gleiche gemacht wird?

Ich arbeite zur Zeit mit einem Skript, welches 4 Parameter übergeben werden

1. ein Startdatum

2. eine Startuhrzeit

3. Minuten (Im Skript werden die Minuten zur Startzeit addiert um ein ein anderes Programm mit dieser Uhrzeit/Datum ein Bild berechnen zu lassen)

4. AnzahlBilder (so viele Bilder sollen gemacht werden)

Oft weiß ich nicht mehr, ob ich nun zuerst Minuten oder AnzahlBilder eingeben muss 😊

Wer mehr als 9 Parameter an ein Skript übergeben möchte, sollte der nicht lieber mit "-option wert" Paaren arbeiten? Also in meinem Skript zum Beispiel:

./make_pictures.sh -startdatum Datum -uhrzeit Uhrzeit -minuten Minuten -anzbilder Bilder 

❓

Vllt ist shift gar nicht so gebräuchlich, als das man dafür ein konkretes Beispiel bräuchte?

Gruß
kaputtnik