Bash: "value too great for base (error token is "09")" ???

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • So, Guten Tag ihr lieben,

    Dank eurer gestrigen Hilfe ( :thumbs1: )bin ich mit meinem Skript quasi schon am Ziel. Nur tritt manchmal ein Fehler auf der es zum Abstürzen bringt! Die Fehlermeldung ist irgendwie nicht aufschlussreich :no_sad:
    Hier zunächst das Skript:

    Ziel ist die Systemzeit zu vergleichen mit der Zeit die durch Daten von einem GPS-Modul über die serielle Schnittstelle übertragen werden (GPIO 6/8). Die Differenz wird berechnet und nach ihrer Größe wird (später mal) entschieden ob die Systemzeit nun bereits vom GPS-Modul gestellt wurde oder noch nicht. Egal, das nur am Rande.

    Das Skript enthält bereits einige Ausgaben die nur zur Fehlereinkreisung eingefügt wurden.
    In den allermeisten Fällen ist die Ausgabe etwa so:

    pi@Pi7:~/script $ sudo ./temp

    36476
    10:07:57
    10
    07
    57
    36477
    delta = 1
    Hurra, die Zeit synchronisation ist erfolgt!
    36477
    10:07:58
    10
    07
    58
    36478
    delta = 1
    Hurra, die Zeit synchronisation ist erfolgt!
    36479
    10:08:00
    10
    08
    00
    ./temp: line 22: 08: value too great for base (error token is "08")
    pi@Pi7:~/script $


    Weil im Skript a=0 auskommentiert ist läuft die Schleife immer durch (auch nur zu Testzwecken). Jetzt: Immer wenn die Minuten oder die Sekunden der GPS-Zeit "08" sind, dann stürzt das Skript ab. Die Fehlermeldung macht für mich irgendwie keinen Sinn. Bei "04" oder bei "10" passiert das nicht. Komisch :s :s

    Frage: Sieht da jemand von euch die Ursache?

    Ich könnte damit leben wenn der Fehler ab und zu auftritt aber das Skript sollte nicht abstürzen sondern die Schleife einfach nochmal durchlaufen lassen.

    Einmal editiert, zuletzt von Stef7 (27. Juli 2017 um 13:06)

  • Bash: "value too great for base (error token is "09")" ???? Schau mal ob du hier fündig wirst!

  • Naja, guck dir doch einfach mal deine Debug-Ausgaben an und schau dann welche bei dem Problem fehlt... Dafür hast du doch diese Debug-Ausgaben eingebaut oder nicht?

    1. Durchlauf:

    Code
    36476
    10:07:57
    10
    07
    57
    36477
    delta = 1
    Hurra, die Zeit synchronisation ist erfolgt!

    2. Durchlauf:

    Code
    36477
    10:07:58
    10
    07
    58
    36478
    delta = 1
    Hurra, die Zeit synchronisation ist erfolgt!

    3. Durchlauf:

    Code
    36479
    10:08:00
    10
    08
    00
    ./temp: line 22: 08: value too great for base (error token is "08")

    Die Fehlermeldung sagt auch in welcher Zeile des Scripts der Fehler aufgetreten ist.

    Gemäß der Bugausgabe scheint das Problem also hier zu hängen:

    Code
    echo $seconds
    gpssec=$((hours*3600 + minutes*60 + seconds*1))
    echo $gpssec

    $seconds wird noch ausgegeben danach kommt der Fehler....

  • Hallo, versuch mal die erste stelle, also die null noch wegzuschneiden, also bei allen Zahlen die kleiner 10 sind.

    Oder benötigst du die 0 unbedingt?

    Gesendet von meinem SM-N910F mit Tapatalk


    Was natürlich auch geht, die Uhrzeit grundsätzlich einstellig ausgeben.

    Einmal editiert, zuletzt von roland.b (27. Juli 2017 um 13:09)

  • Zitat von "meigrafd" pid='292829' dateline='1501153557'


    Naja, guck dir doch einfach mal deine Debug-Ausgaben an und schau dann welche bei dem Problem fehlt... Dafür hast du doch diese Debug-Ausgaben eingebaut oder nicht?


    Ja genau so ist es! Und was würdest du vermuten, habenich mir die Ausgaben bereits angesehen, nachdem ich sie eingebaut habe, oder nicht?
    Und weiter, würde ich hier die entsprechenden Fragen stellen wenn ich mit den Debug-Ausgaben weitergekommen wäre?
    Ich geh auch nicht davon aus dass du davon ausgehst dass ich mir die Ausgaben nicht angesehen habe. Was ich mich allerdings frage ist, warum du mich das fragst!?


    Zitat von "meigrafd" pid='292829' dateline='1501153557'


    3. Durchlauf:

    Code
    36479
    10:08:00
    10
    08
    00
    ./temp: line 22: 08: value too great for base (error token is "08")


    Ja, hier tritt das Problem auf. Wie gesagt, bei "04" z.B. gibt es keine Probleme, also wird die vorangestellte "0" wohl nicht das Problem sein. Auch "00" ist kein Problem, die Schleife stürzt nur bei "08" ab. Und dafür habe ich keine Erklärung, und deswegen frage ich hier mal nach! Denn vielleicht sieht ja jemand die Ursache!

    Hier nochmal ein Beispiel wo das Problem bei den Sekunden auftritt:


    PS: In der Formal zur Berechnung der Gesamtsekunden ist das "seconds*1" natürlich schon ein Test, ob es einen Unterschied zu "seconds", also ohne *1 macht. Tut es erwartungsgemäß aber nicht...

    Einmal editiert, zuletzt von Stef7 (27. Juli 2017 um 13:24)

  • [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]> Und dafür habe ich keine Erklärung[/font]
    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Zahlen mit fuehrender 0 werden als Oktal-Zahl interpretiert.[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]00 ist gueltig, 07 auch, aber 08 nicht mehr[/font]

  • Zitat von "Tell" pid='292834' dateline='1501154582'


    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]> Und dafür habe ich keine Erklärung[/font]
    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Zahlen mit fuehrender 0 werden als Oktal-Zahl interpretiert.[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]00 ist gueltig, 07 auch, aber 08 nicht mehr[/font]

    Danke das klingt schon mal sinnvoll!
    Muss ich jetzt eine Fallunterscheidung machen, nach dem Motto "Wenn erstes Zeichen == 0, dann seconds=${time2:7:1}" oder kann ich irgendwo definieren dass alle Zahlen als Dezimalzahlen zu interpretieren sind? Eleganz und so...
    Automatisch zusammengefügt:

    Zitat von "Manul" pid='292836' dateline='1501154860'


    Was Tell sagt. Die unkomplizierte Variante, die ich im anderen Thread vorgeschlagen habe und bei der Du Dir die Rechnerei komplett sparst, wolltest Du nicht umsetzen?

    Du meinst das von gestern, die Ausgabe der Sekunden seit 1970?
    Das wäre zwar elegant aber ich kann die Zeit die ich vom GPS-Modul bekomme nicht in diesem Formal ausgeben lassen. Es ist reiner Text der vom GPS-Modul mit 9600 baud über die serielle Schnittstelle reinkommt. Ich bin schon erstaunt dass ich den Text nicht in Zahl wandeln muss. Aber es wäre sicher noch mehr Rechnerei wenn ich die GPS-Zeit "manuell" in dieses Format bringen müsste. Also ist die aktuelle Lösung wohl schon die beste.

    OK, wenn keiner mehr eine Idee hat wie man definieren kann dass die Zahl stets als Dezimalzahl zu interpretieren ist dann würde ich jetzt wirklich mittels if-Abfrage die vordere "0" wegschneiden wenn sie existiert...

    Einmal editiert, zuletzt von Stef7 (27. Juli 2017 um 13:36)

  • Ich habe doch im anderen Thread auch gezeigt, wie Du die GPS-Zeit in das Format bekommst. Auch da ist nix mit manuellem Umrechnen. Wie sieht denn die GPS-Ausgabe genau aus?

    Einmal editiert, zuletzt von Manul (27. Juli 2017 um 13:55)

  • Zitat von "Manul" pid='292843' dateline='1501156469'


    Wie sieht denn die GPS-Ausgabe genau aus?


    Folgendermaßen:

    Code
    pi@Pi7:~ $ gpspipe -w -n10 | grep -m1 TPV | cut -d'"' -f18
    2017-07-27T12:00:57.000Z

    Ich habe mittlerweile unter

    Code
    date --help

    gefunden dass ich zumindest die Systemzeit auch im Format

    Code
    date +"%_H:%_M:%_S"

    ausgeben lassen kann. So kann ich schonmal 3 der if-Abfragen sparen :lol:

  • Er meint das hier:

    Zitat von "Manul" pid='292623' dateline='1501066167'


    Noch besser fände ich allerdings

    Code
    gpszeit=$(date +%s -d $(gpspipe -w -n10 | grep -m1 TPV | cut -d'"' -f18 | cut -d'T' -f2 | cut -c 1-8))
    syszeit=$(date +%s)

    Das liefert Dir beide Zeiten als Unix-timestamp (Sekunden seit 1970-01-01 00:00:00 UTC). Die kannst Du direkt vergleichen und sparst Dir auch eventuelle Zeitzonenumrechnungen.

    Du erhälst von deinem GPS eine Zeit:

    Code
    time2=$(gpspipe -w -n10 | grep -m1 TPV | cut -d'"' -f18 | cut -d'T' -f2 | cut -c 1-8)

    Dabei rauskommen tut zB => 10:07:57
    Was du anschließend machst ist eine eher komplizierte Zerlegung:

    Code
    hours=${time2:0:2}
    minutes=${time2:3:2}
    seconds=${time2:6:2}

    ...das birgt Probleme wenn es kein 24h Format ist und sich somit die Stelle verschieben, aber das sei nur nebenbei erwähnt.

    Mit dem Unix-Timestamp lässt sich wie ich finde einfacher arbeiten. Beispielsweise wandelst du 10:07:57 dahingehend um:

    Code
    date -d "10:07:57" +%s

    Ausgabe: 1501142877

    Und dann kannst du dir davon wie du möchtest den entsprechenden Wert raus lutschen:

    Code
    date -d @1501142877 +%H
    10
    date -d @1501142877 +%_M
     7
    date -d @1501142877 +%S
    57

    Ein weiterer Vorteil durch Unix-Timestamp ist allerdings - und das ist vermutlich das entscheidende - das du gar keine Berechnung ala $((hours*3600 + minutes*60 + seconds*1)) benötigst, da der timestamp bereits in Sekunden ist.
    Allerdings musst du dann nicht nur die Uhrzeit sondern ggf. Datum etc auch beim "date -d "10:07:57" +%s" verwenden, sonst wird von "heute" ausgegangen.

  • Zitat

    OK, wenn keiner mehr eine Idee hat wie man definieren kann dass die Zahl stets als Dezimalzahl zu interpretieren ist...


    Dies kannst du erreichen, indem du der Variablen die Basis (Dezimal -> 10), gefolgt von einer Raute voranstellst:

    Code
    #! /bin/bash
    number=08
    echo $(( 10#$number * 2 ))

    Einmal editiert, zuletzt von rastafari (27. Juli 2017 um 14:39)

  • Zitat von "meigrafd" pid='292848' dateline='1501158082'


    Ein weiterer Vorteil durch Unix-Timestamp ist allerdings - und das ist vermutlich das entscheidende - das du gar keine Berechnung ala $((hours*3600 + minutes*60 + seconds*1)) benötigst, da der timestamp bereits in Sekunden ist.

    Eben. Genau das meinte ich.

    Zitat von "meigrafd" pid='292848' dateline='1501158082'


    Allerdings musst du dann nicht nur die Uhrzeit sondern ggf. Datum etc auch beim "date -d "10:07:57" +%s" verwenden, sonst wird von "heute" ausgegangen.

    Ist zwar prinzipiell natürlich richtig, aber da es ja nur darum geht, ob beide Zeiten sekundengenau übereinstimmen, fällt das in diesem Fall nicht ins Gewicht, da ohnehin mit einer Zeit von "heute" verglichen wird.

    Außerdem akzeptiert date übrigens auch direkt das oben angegebene Zeitformat:

    Code
    > date +%s -d 2017-07-27T12:00:57.000Z
    1501156857
  • Zitat von "meigrafd" pid='292848' dateline='1501158082'


    Er meint das hier:


    Tatsächlich! Diese Zeilen von Manul hatte ich übersehen.
    Und tatsächlich, es funktioniert so! Beeindruckend!

    Nochmals Danke an Manul und euch alle! :danke_ATDE:

    Mein finales Testskript (das vorherige mit den vielen Unterscheidungen und Berechnungen lief mittlerweile auch vollständig) ist nun also erheblich verkürzt und sieht jetzt so aus:

    Ausgabe ist z.B.

    1501163381
    1501163382
    delta = 1
    Hurra, Zeitabgleich ist erfolgt! :thumbs1:

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!