Arch Linux

Shellscript: Zählschleife / Zahlenproblem

Square

Moin 🙂
Ich brauche grade als teil eines scripts folgende variable:
archiv0101
der name setzt sich zusammen aus:

archivname=`echo "archiv$wert1$wert2"`

wert1 bleibt immer gleich auf 01
wert2 soll sich jedoch nach jedem schritt um eins erhöhen,
also folgende werte erhalten:
01
02
...
...
09
10
11
usw...
Versucht habe ich das folgendermaßen:

wert2=01
wert2=$[$wert2+1]

allerdings kommt ab dann jedesmal 2,3,4 etc., also ohne die vorangehende 0.
Kann mir jemand einen tipp geben wie ich mit den zahlen so umgehen kann? Also eben die Null bei jeder zahl kleiner als 10 mitdrann zu bekommen.

Kinch

Also ich glaube das ist wirklich der abenteuerlichste Shell-Code den ich je gesehen habe:

archivname=`echo "archiv$wert1$wert2"`

Warum tut es nicht auch ein:

archivname="archiv$wert1$wert2"

?

Bei Shell-Script-Fragen, wäre es auch nett, wenn sich mal einbürgern würde, dass man sagt, um welche Shell es sich handelt.

Hier ne Lösung, die zumindest bei der Z-Shell funktioniert:

for wert2 in {01..100}
do
echo $wert2
done

hydro

Ich habe das in bash neulich so gemacht

var=0${var}
var=${var:${#var}-2}

also erst einmal eine null vorne dranhängen und dann nur die letzten zwei Stellen berücksichtigen.
Wenn nur eine Zahlenfolge erzeugt werden soll, ist Kinchs Vorschlag natürlich vorzuziehen. Ginge übrigens auch mit seq, ist aber schlechter Stil.

seq -f "01%02g" 1 11

Dirk

Square schriebAlso eben die Null bei jeder zahl kleiner als 10 mitdrann zu bekommen.

$ seq -w 1 10
01
02
03
04
05
06
07
08
09
10

domachine

hydro schriebIch habe das in bash neulich so gemacht
Ginge übrigens auch mit seq, ist aber schlechter Stil.
seq -f "01%02g" 1 11

Könntest du erläutern, weshalb du das als schlechten Stil bezeichnest?

hydro

Naja, weil ein externes Programm für etwas aufgerufen wird, das die Bash von sich aus ebensogut (und schneller) erledigen kann, aber Stilfragen sind mir eigentlich egal, ich weiß nicht mehr genau, warum ich das so bezeichnet hatte.

Dirk

hydro schriebNaja, weil ein externes Programm für etwas aufgerufen wird, das die Bash von sich aus ebensogut (und schneller) erledigen kann,

Es gibt aber nicht nur die Bash, also ist der Aufruf eines externen Programmes sogar BESSERER Stil, weil die Kompatibilität zu anderen SHells höher ist – Außer natürlich, du willst die Bash erzwingen.

hydro

Das klingt jetzt aber etwas abenteuerlich. Für möglichst viele Funktionen externe Programme aufrufen, auch wenn ein etwas komplexeres Script dann ewig und drei Tage braucht? In der ersten Zeile des Scriptes steht, welche Shell das Script interpretieren soll, und dann erwarte ich auch, dass mir alle Funktionen dieser Shell zur Verfügung stehen.

Dirk

hydro schrieb… und dann erwarte ich auch, dass mir alle Funktionen dieser Shell zur Verfügung stehen.

Nur dass /bin/bash nicht immer und überall auf „GNU bash, Version 4.2.20“ verweist.

hydro

Ja, ich weiß. Für überschaubare Befehle auf der Kommandozeile nutze und kombiniere ich gern auch alle verfügbaren Programme, aber bei Scripten erweisen diese sich (insbesondere innerhalb einer Schleife vielfach aufgerufen) auf älteren Rechnern halt oft als Bremse.

domachine

hydro schriebJa, ich weiß. Für überschaubare Befehle auf der Kommandozeile nutze und kombiniere ich gern auch alle verfügbaren Programme, aber bei Scripten erweisen diese sich (insbesondere innerhalb einer Schleife vielfach aufgerufen) auf älteren Rechnern halt oft als Bremse.

Ich will diese Diskussion jetzt nicht unnötig ausweiten. Aber ich würde bei Shell-Scripten keinesfalls mit Performance argumentieren. Shell-Scripte wurden ursprünglich entworfen um aus verschiedenen Unix-artigen Programmen eigene Funktionalitäten (Scripte eben) zu gestalten. Wenn die Performance eine Rolle spielt, sollte von Shell-Scripten tunlichst abgeraten werden. Und glaube mir, ein Shell-Script wird nicht nennenswert (Als nennenswert bezeichne ich hier „für den Benutzer spürbar”) langsamer, wenn externe Befehle statt Shell-Builtins verwendet werden. Dafür sind moderne Prozessoren viel zu smart beim Abspalten von Prozessen. Ich habe jetzt zu wenig Zeit, hierfür Beweise anzuführen, da ich auf dem Sprung zur Arbeit bin. Aber ich bin mir fast sicher 🙂.

Gruß Dominik

hydro

Also mal ein Beispiel, jetzt nicht auf seq, sondern auf cut bezogen: In einer Textdatei befinden sich Datensätze (7 Felder, durch "|" getrennt), die zeilenweise in ein Array eingelesen und danach weiterverarbeitet werden sollen. Könnte man so machen

while read line ; do
  for i in $(seq 0 6); do
    var[$i]=$(echo $line | cut -d\| -f $((i+1)))
  done
  # ...
done < data.txt

oder so

while read line ; do
  for i in $(seq 0 6); do
    var[$i]=${line%%|*}
    line=${line#*|}
  done
  # ...
done < data.txt

Das Vermeiden des Aufrufs von cut für jeden Datensatz verzehnfacht die Geschwindigkeit

$ wc -l data.txt 
100 data.txt
$ time bash script1.sh 

real	0m5.544s
user	0m0.230s
sys	0m0.443s
$ time bash script2.sh 

real	0m0.545s
user	0m0.110s
sys	0m0.083s

Der Unterschied ist für mich schon deutlich spürbar, insbesondere im Verlauf der Erstellung und des Testens eines Scriptes, und solange ein Script dann in vertretbarer Zeit seinen Dienst tut, greife ich noch nicht zum Compiler.

Dirk

$ time dash script2.sh
script2.sh: 3: script2.sh: var[0]=ersterwert: not found

hydro

Das hatten wir doch schon und darum ging es nicht. Die dash kennt keine Arrays, also funktionieren damit beide Scripte nicht.

domachine

hydro schrieb
$ wc -l data.txt
100 data.txt
$ time bash script1.sh

real	0m5.544s
user	0m0.230s
sys	0m0.443s
$ time bash script2.sh

real	0m0.545s
user	0m0.110s
sys	0m0.083s
Der Unterschied ist für mich schon deutlich spürbar, insbesondere im Verlauf der Erstellung und des Testens eines Scriptes, und solange ein Script dann in vertretbarer Zeit seinen Dienst tut, greife ich noch nicht zum Compiler.

Ich finde in diesem Fall sind 5s Laufzeit für ein Shellscript durchaus vertretbar. Aber sachlich gesehen ist das natürlich ein schlechtes Argument. Ich denke, ich muss meine Antwort aber auch etwas revidieren. Im Grunde kommt es wahrscheinlich darauf an, auf was man Wert legt (Kompatibilität vs. Performance). Mir ist es lediglich etwas sauer aufgestoßen, als Du den Einsatz externer Werkzeuge als „schlechten Stil” bezeichnet hast. Das ist meiner Meinung nach eine gewagte Äußerung.

Gruß Dominik

hydro

domachine schrieb den Einsatz externer Werkzeuge als „schlechten Stil” bezeichnet hast. Das ist meiner Meinung nach eine gewagte Äußerung.

Da gebe ich dir recht, ich habe die Aussage ja mit #6 schon quasi zurückgezogen.

oenone

hydro schrieb

while read line ; do
  for i in $(seq 0 6); do
    var[$i]=${line%%|*}
    line=${line#*|}
  done
  # ...
done < data.txt

Nicht wirklich lesbar.. In ein paar Monaten fragst du dich dann, wtf du da gemacht hast.

hydro schriebDer Unterschied ist für mich schon deutlich spürbar, insbesondere im Verlauf der Erstellung und des Testens eines Scriptes, und solange ein Script dann in vertretbarer Zeit seinen Dienst tut, greife ich noch nicht zum Compiler.

Gerade bei der Entwicklung sollte man nicht auf Geschwindigkeit achten, sondern auf Korrektheit und Lesbarkeit. Optimieren kann man später immer noch.

hydro

oenone schrieb Nicht wirklich lesbar.. In ein paar Monaten fragst du dich dann, wtf du da gemacht hast.

Wenn du die Stringmanipulationen meinst, die habe ich in meinen Linux Anfangstagen dem Kofler entnommen und seither dankbar verinnerlicht.

domachine

oenone schrieb Nicht wirklich lesbar.. In ein paar Monaten fragst du dich dann, wtf du da gemacht hast.

Sag mal, ist Dir der Kontext der Diskussion nicht ersichtlich geworden? Er hat den Code geschrieben um eine Laufzeitanalyse durchzuführen. Es ist verständlich, dass der „quick-and-dirty” ist.

Gerade bei der Entwicklung sollte man nicht auf Geschwindigkeit achten, sondern auf Korrektheit und Lesbarkeit. Optimieren kann man später immer noch.

Entschuldige aber das hat meiner Meinung nach wirklich gar nichts mit dem Thema der Diskussion zu tun.

Gruß Dominik

portix

Wenn man auf Laufzeit Wert legt kann es sinnvoller sein dash statt bash zu nehmen, die nunmal nur den POSIX-Standard kennt, der übrigens auch Stringerzetzung umfasst.

#!/bin/bash 

while read line; do 
  echo ${line} > /dev/null
done < datei.txt

$ time ./bash.sh

real	0m4.141s
user	0m3.446s
sys	0m0.680s

und

#!/bin/dash 

while read line; do 
  echo ${line} > /dev/null
done < datei.txt

$ time ./dash.sh

real	0m1.563s
user	0m0.667s
sys	0m0.877s

Anhand synthethischer Skripts lässt sich imho gar nicht sagen, was die beste Lösung ist, allerdings ist es bei Skripts die eventuell noch andere benutzen immer sinnvoll POSIX einzuhalten.

Nächste Seite »

Datenschutz
Impressum