^ ^ getmsg xyz.net '/call.php?nr=%s&called=%s&wer=fritzchen' "$SOURCE" "$DEST"
Das finde ich ziemlich seltsam; wenn nc auf eine Verbindung oder weitere Daten wartet, sollte es doch theoretisch keine CPU-Zeit brauchen.mfischer-ffb schrieb:laut top 97% cpu last.
Es wird schon der Schalter -w von nc benutzt, aber mir ist auch schon aufgefallen, dass der nicht in jedem Fall nach soundsoviel Sekunden nc beendet:kann man in das script nicht einen timeout einbauen wenn das oertliche mal nicht geht ??
-w SECS timeout for connects and final net reads
Stimmt, war mir gar nicht mehr bewusst. In callmonitor.sh ist noch der entsprechende Kommentar drin. Das ganze scheint wirklich ein Bug in dem busybox-ash zu sein; ich werde das noch mal genauer angucken und dann einen Bug Report fertigmachen.fritzchen schrieb:wenn keine Nummer übermittelt wird, rutscht $CALLED nach vorne und kommt als $MSISDN an. Ich glaube das hatten wir schon mal?
/var/mod/root # set -- "" "a" "b"
/var/mod/root # for x in "$1" "$2" "$3"; do echo "|$x|"; done
||
|a|
|b|
/var/mod/root # for x in "$@"; do echo "|$x|"; done
|a|
|b|
Der Fehler tritt auf in busybox-1.01; ich habe gerade mal die Preview-Version busybox-1.1.0-pre1 ausprobiert, da ist der Fehler behoben bzw. tritt nicht mehr auf. (Einen passenden Bug-Report oder einen Eintrag im Change Log habe ich noch nicht gefunden; bugs.busybox.net ist im Moment unerträglich langsam.)sascha schrieb:Ich kann diesen Bug bei mir nicht reproduzieren. Muß wohl an der Mod-BusyBox liegen.
Nein, ich habe in beiden geschilderten Fällen "frische" busybox-Sourcen mit dem Compiler (gcc 4.0.2) für mein Desktop-System übersetzt. Und sowohl deine mips-Version als auch meine i686-Version haben das gleiche $@-Verhalten in der busybox 1.01 gezeigt.danisahne schrieb:@buehmann:
Hast du versucht die Version der Busybox, die im Mod ist, (also 1.01 im source Verzeichnis) mit deinem Compiler zu kompilieren?
das Problem könnte sein, dass die DBox eine andere Zeichenkodierung haben will (dasoertliche.de benutzt Latin1; in der Form steht es momentan auch in SOURCE_NAME). Wenn jetzt die DBox zum Beispiel UTF-8 erwartet, gibt es natürlich Müll bei den Umlauten. Mangels DBox konnte ich noch nicht ausprobieren, welche Kodierung die DBox erwartet. Vielleicht kannst du mir dabei helfen.IngoB schrieb:Die Umlaute habe ich auch entsprechend ersetzt (ä=ae), da die DBox sich weigert Umlaute anzuzeigen. Vielleicht gibt es ja entsprechende Ersatzzeichen?
^ ^ dboxpopup 192.168.1.2 "$(echo "$SOURCE_NAME" | latin1_utf8)"
Am liebsten würde ich die "echten" Umlaute zum Laufen bekommen; vielleicht schaffen wir das ja.Wäre vielleicht eine gute Idee, diese Ersetzungen in die dboxpopup-Funktion einzubauen...
Ja - das klapptbuehmann schrieb:Code:^ ^ dboxpopup 192.168.1.2 "$(echo "$SOURCE_NAME" | latin1_utf8)"
Schön, dann baue ich die Konvertierung nach UTF8 bald in die beiden dbox-Funktionen ein.IngoB schrieb:Ja - das klappt
Ok, macht das sowohl für dboxpopup als auch für dboxmessage Sinn? (Was ist eigentlich der genaue Unterschied zwischen den beiden Varianten?)Man sollte nur noch (wg. der Übersichtlichkeit) die "," durch ein Newline ersetzen..
dboxpopup: Meldung erscheint für einige Sekunden auf dem Bildschirm und verschwindet automatisch wieder.buehmann schrieb:Ok, macht das sowohl für dboxpopup als auch für dboxmessage Sinn? (Was ist eigentlich der genaue Unterschied zwischen den beiden Varianten?)