fhem.pl anpassen für stateFormat

[justme1968]

bis auf . und / finde ich das gut. der . macht keine probleme und wird an vielen stellen verwendet. das gleiche gilt für /.

[Markus Bloch]

Nunja der Punkt eigentlich um Verwechslungen und Missgeschicke bei Regexp-Prüfungen zu vermeiden.

Der Slash mag sein, dass er keine Probleme macht, aber mal ehrlich, was hat der in einem Identifier zu suchen?

[justme1968]

der punkt ist ideal um hierarchisch zu trennen. dazu wird er viel verwenden. der slash taucht z.b. beim plattenplatz überwachen auf.

[viegener]

Ich denke das Semikolon sollte auch eher ausgeschlossen werden.
Dafür verstehe ich wenn man den Punkt als Strukturierungselement erhalten möchte.

Das mit den non-ASCII-Zeichen sollte aber gut überlegt werden, das mit den Smilies ist ja nur als Witz gedacht, aber schon die Umlaute bereiten immer wieder Probleme, da wir immer wieder auch mit externen Systemen kommunizieren, die zum Teil sehr eigenwillige Vorstellungen haben (Perl selbst hat gelegentlich schon eigenwillige Meinungen über den Inhalt von Strings).

Wie wäre es generelle Unicodezeichen (non-Ascii) nicht explizit auszunehmen aber nicht für Identifier zu empfehlen?

[Markus Bloch]

Stimmt, dass Semikolon hatte ich nur vergessen, ist aber auch meine Meinung das auszuschließen (wegen Kommando-Verkettungen).

Daher nochmal mein Vorschlag:

[ ] { } ( ) , . : ; * + ? \ / @ % $ ^

[rudolfkoenig]

Na so trivial ist es mit der Negativliste auch nicht. Tipp mal "man ascii" in einem shell-Fenster, und ueberlege fuer alle angezeigten Character, ob es in einem Device-,Reading-, oder Attributnamen sinnvoll waere. Ich finde auf Anhieb noch nul-bis-space ! " # & ' < > = ` | ~

Wenn wir Umlaute wollen, kommt die nicht zu unterschaetzende Umstellung auf interne UTF Darstellung dazu, d.h. alle Schnittstellen, die interne IDs nach "aussen" kommunizieren, eine Konvertierung durchfuehren muessen, sonst faellt gzip/write/etc auf die Nase. Bisher fahren wir die entgegengesetzte Strategie: alles was reinkommt, muss nach "ein-Byte" Zeichen konvertiert werden, und alles was rausgeht, ist egal.

Bisher gab es fuer Devicenamen ein alias Attribut, und Reading/Attribut war nicht begrenzt.
Wenn wir anfangen zu begrenzen, dann bleibt Reading/Attribut zunaechst aussen vor.

[viegener]

NUL würde ich auschliessen, auch wenn es perl ist und nicht C 

Im Ernst, Du hast völlig Recht, die Liste muss wohl noch erweitert werden (was dann auch wieder die Frage stellt, ob eine Positivliste nicht besser wäre). Also hier man der Versuch einer vollständigen (ASCII-)Liste, mit Info was erlaubt sein könnte --> unten:

Bei einigen bin ich mir sehr unsicher, ob es potentiell nicht doch erlaubt sein sollte (z.B. warum kein $ oder @).
Ausserdem die Frage, ob es noch einen Unterschied zwischen dem ersten Zeichen und dem Rest geben sollte (viele Sprachen machen da einen Unterschied)...



HEX 00-20 / NUL bis SPACE - NEIN

HEX 21 - ! - ??
HEX 22 - " - NEIN
HEX 23 - # - NEIN
HEX 24 - $ - NEIN
HEX 25 - % - NEIN
HEX 26 - & - ??
HEX 27 - ' - NEIN
HEX 28/29 - () - NEIN
HEX 2A - * - ??
HEX 2B - + - ??
HEX 2C - , - NEIN
HEX 2D - - - NEIN
HEX 2E - . - JA
HEX 2F - / - ??

HEX 30-39 - 0-9 - JA

HEX 3A - : - NEIN
HEX 3B - ; - NEIN
HEX 3C - < - NEIN
HEX 3D - = - NEIN
HEX 3E - > - NEIN
HEX 3F - ? - NEIN
HEX 40 - @ - ??

HEX 41-5A - A-Z - JA

HEX 5B - [ - NEIN
HEX 5C - \ - NEIN
HEX 5D - ] - NEIN
HEX 5E - ^ - ??
HEX 5F - _ - JA
HEX 60 - ` - NEIN

HEX 61-7A - a-z - JA

HEX 7B - { - NEIN
HEX 7C - | - NEIN
HEX 7D - } - NEIN
HEX 7E - ~ - ??
HEX 7F - DEL - NEIN

[Wernieman]

Ich würde den "." nicht erlauben. Er wird in Regexp verwendet ... sonst müssen wir anfangen, dort mit Quotas zu arbeiten...
Aus den gleichen Gründen auch Zeichen wie "*"

[betateilchen]

Wenn wir anfangen zu begrenzen, dann bleibt Reading/Attribut zunaechst aussen vor.

äh... darf ich daran erinnern, dass wir hier ursprünglich über readings diskutierten und der Vorschlag der Ausweitung auf device und attribute danach aufkam?

[viegener]

Ich würde den "." nicht erlauben. Er wird in Regexp verwendet ... sonst müssen wir anfangen, dort mit Quotas zu arbeiten...
Aus den gleichen Gründen auch Zeichen wie "*"

Kannst Du mir auf die Sprünge helfen? Mir fällt gerade kein Fall ein, wo Namen von devices etc als Regexp verwendet werden? Wenn man nach einem Devicenamen etc in einem Ausdruck sucht, würde ich schon heute eher Index verwenden, denn es kann ja heute nicht ausgeschlossen werden.

[Wernieman]

??

Wenn ich bei mir z.B. bei den Logfiledefinitionen nachschaue:

Code Auswählen Erweitern

./log/MacFritzboxLog-%Y.log Fritzbox:mac_.*

Wenn jetzt in "Fritzbox", welches ein Device ist, ein "." enthalten währe, also z.B.

Code Auswählen Erweitern

Fritz.box:mac_.*
Würde dieses auf alles matchen, wie z.B. Fritz-box, Fritz1box, Fritz2box .. ohne das einem 0815-User es bekannt ist.

Oder habe ich es jetzt falsch verstanden?

[marvin78]

Sollte der . in Devicenamen verboten werden, ist hier wohl die Hölle los. Alleine deshalb:

http://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html

Ich sehe da auch keinerlei Problem. Wenn man mit Regexp arbeitet, sollte auch 0815-User sich informieren, wie das geht.

[Wernieman]

sollte auch

Genau dort sehe ich das Problem ;o)

[viegener]

Wenn ich bei mir z.B. bei den Logfiledefinitionen nachschaue:

Code Auswählen Erweitern

./log/MacFritzboxLog-%Y.log Fritzbox:mac_.*

Wenn jetzt in "Fritzbox", welches ein Device ist, ein "." enthalten währe, also z.B.

Code Auswählen Erweitern

Fritz.box:mac_.*
Würde dieses auf alles matchen, wie z.B. Fritz-box, Fritz1box, Fritz2box .. ohne das einem 0815-User es bekannt ist.

Danke, das hilft! Ich hatte nur aus Modulsicht gedacht und dabei war mir kein Fall geläufig. Wobei das Problem jetzt auch bei Events (und anderen Stellen) auftreten könnte. Damit haben gibt es eigentlich schon jetzt ein Problem für die Nutzer.

[justme1968]

ich finde diesen fall nicht kritisch.

zum einen ist der fall nicht häufig (sonst würde das jetzt schon probleme machen) und zum anderen matched es im problemfall auf zu viele devices. was dann recht schnell sichtbar ist und man kann fragen und helfen.

schlimm wäre es wenn es auf zu wenig devices matchen würde oder devices nicht sichtbar sind.