Die Vornull in den (inzwischen) erreichten Versionsnummern stellte tatsächlich das Problem dar ... lt. POSIX-Standard sind Zahlen
mit führender Null immer oktal, weil man da den ISO-C-Standard adoptiert hat:
Only the decimal-constant, octal-constant, and hexadecimal-constant constants specified in the ISO C standard, Section 6.4.4.1 are required to be recognized as constants.
und da sieht das Grammar so aus (die Suffix-Optionen kennt die Shell dann auch nicht):
Code:
integer-constant:
decimal-constant integer-suffixopt
octal-constant integer-suffixopt
hexadecimal-constant integer-suffixopt
decimal-constant:
nonzero-digit
decimal-constant digit
octal-constant:
0
octal-constant octal-digit
hexadecimal-constant:
hexadecimal-prefix hexadecimal-digit
hexadecimal-constant hexadecimal-digit
hexadecimal-prefix: one of
0x 0X
nonzero-digit: one of
1 2 3 4 5 6 7 8 9
octal-digit: one of
0 1 2 3 4 5 6 7
hexadecimal-digit: one of
0 1 2 3 4 5 6 7 8 9
a b c d e f
A B C D E F
integer-suffix:
unsigned-suffix long-suffixopt
unsigned-suffix long-long-suffix
long-suffix unsigned-suffixopt
long-long-suffix unsigned-suffixopt
unsigned-suffix: one of
u U
long-suffix: one of
l L
long-long-suffix: one of
ll LL
Damit wird
jede Variable mit einer Null am Beginn in einem arithmetischen Kontext automatisch zur Oktalzahl (soweit hatte
@H'Sishi ja recht mit seiner Annahme - lt. der Grammatik oben kann eine Dezimalzahl nicht mit einer Null beginnen, da sind nur "non-zero digits" erlaubt) und da die Formatzeichenkette mit dem "%d" den Wert dann automatisch in einen solchen arithmetischen Kontext rückt, wird zuvor die Umwandlung versucht, die bei Ziffern außerhalb von 0 bis 7 eben fehlschlägt (bzw. mit der entsprechenden Warnung versehen wird, denn die gültigen Ziffern werden trotzdem umgewandelt):
Code:
vidar:/home/GitHub/YourFritz/juis $ printf "%d\n" 01234ABC
bash: printf: 01234ABC: invalid octal number
668
vidar:/home/GitHub/YourFritz/juis $
Ich werfe jetzt von diesen numerischen Werten (nur Major, Minor und Patch sind für mich da relevant, mit anderen muß das Skript nicht rechnen) einfach die Vornullen weg, wobei man aufpassen muß, daß die letzte Null noch übrigbleibt, wenn der Wert tatsächlich 0 ist.
Ich habe mich für:
Code:
value=$(expr "$value" : "0*\([0-9]\+\)")
entschieden, obwohl man das wahrscheinlich auch mit anderer Syntax hätte machen können. Aber so klappt es wenigstens mit demselben (und einem einzigen) Statement auch ohne Vornullen und mit beliebig vielen, bis hin zu Werten aus einer oder mehreren Nullen.
Damit wurde das tatsächlich dadurch ausgelöst, daß AVM wieder bei "0x" als "Patch" angekommen ist - ab FRITZ!OS 8 wäre es ebenfalls schief gegangen. Die "Buildnumber" hatte ich hingegen von Beginn an nur als "string" verwendet, daher haben die Ziffern jenseits der 7 in diesem Wert den Fehler nicht getriggert - das verwirrte mich etwas bei der Suche; genauso die Tatsache, daß das eigentliche "printf"-Kommando dann in einer Shell-Variablen "versteckt" ist und damit die Zeilennummer in der Fehlermeldung halt nur die Stelle ist, wo der Fehler ausgelöst wird.
Wie auch immer ... die neue Version ist eingecheckt. Sollte es weiterhin Probleme geben, bitte hier melden ... ich könnte mich beim "expr" auch vertan haben und irgendeinen Grenzfall nicht berüclsichtigen.
-------------------------------------------------------------------------------
@Daniel Lücking:
Ich würde die "Name="-Einträge so gestalten, daß da keine Escapes erforderlich sind ... beide Namen:
Code:
Name="FRITZ\\!\\"
und
Name="FRITZ\\!Box\\7490"
sehen etwas komisch aus. Man muß ja nur die Zeichen maskieren, die in Shell-Code eine spezielle Bedeutung hätten, wie das Leerzeichen (welches als "token delimiter" wirkt in Zeichenketten, die nicht in "quotes" (Single oder Double) eingeschlossen sind) in meinem Beispiel im "usage screen" des Skripts:
Hier wird also das Leerzeichen "maskiert" - das "!" muß (an dieser Stelle) tatsächlich nicht maskiert werden, obwohl es im Shell-Grammar ein "reserved word" ist (steht irgendwo am Beginn noch anders, da war es aber auch noch ein anderes Skript).
In den oben gezeigten Einträgen ist also das Maskieren entweder überflüssig (ja, das Ende im ersten Beispiel wäre sogar ein Syntax-Fehler - damit würde ja das "double-quote" maskiert, wenn die Auswertung nicht durch ein "eval" erfolgen würde, was auch der Grund dafür ist, daß hier doppelte Escapes anzugeben sind anstelle eines einzelnen) oder es fehlt das Zeichen, welches tatsächlich eine besondere Bedeutung hätte.
Es schadet zwar auch nichts, wenn ein einzelnes Zeichen (hier dann die 7 im zweiten Beispiel oben) am Ende maskiert wird, solange das keine spezielle Bedeutung hat ... dann wird das Maskieren einfach ignoriert. Aber es irritiert dann doch irgendwie ...