Hilfe bei der Umstellung von Zahlen auf Textstrings

[TomLee]

OT

Als jüngster in der Runde find ich es total krank was in dieser Welt abgeht.

[Marko1976]

Sorry, aber was ist daran hoffnungslos wenn ich die Wahrheit schreibe?
Das einzige was für die Programmierung relevant ist ist deine eine Aussage:

Code Auswählen Erweitern

Was allerdings eindeutig zu benennen ist, ist die Bedeutung dieser Variablen: sie enthält den aktuellen Wert, mit dem eine von Dir programmierte Schleife (z.B. mit "for") durchlaufen wird.Alles andere was in dem Dokument drin steht bringt für die Programmierung rein gar nichts. Doch genau deine Aussage ist die die in dem Dokument nicht drin steht. Das hat nichts mit Schuld zuschieben zu tun sondern ist eine einfache feststellung.
Das ist doch genauso als wenn ich bei $name alles möglich aufzähle von Aussehen, Einsatzzwecken, Formatierungen etc. aber nicht dazu schreibe das es sich dabei um einen Platzhalter für den Device-Namen handelt. Wer das nicht weiß ist ohne diese Information zwangweise aufgeschmissen.

Und die PN habe ich dir nur geschrieben, weil ich der Meinung bin, das es nicht in ein öffentliches Forum gehört wenn ich dir schreibe, das ich deine frühere Art zu schreiben für unmöglich und geschmacklos halte, deine Persönlichkeit meiner Meinung nach festgefahren ist und du dein Verhalten erst geändert hast, nachdem ich mich mehrfach über deine Popcorn-Posts bei den Admins beschwert habe. Wenn du das lieber öffentlich haben willst, dann bitte. Ich denke es ist wie in der PN geschrieben, das beste du ignorierst mich einfach, denn Freunde werden wir wohl nie mehr werden mit deiner Art der Unverständlichkeit für jemanden der sich nicht mit Perl auskennt.

[passibe]

Ich finde die verlinkte Perl-Doku zum Verständnis bestenfalls auch eher "meh".

Glücklicherweise gibt es ja heute viele AI-Tools, die können sowohl bei sprachlichen Verständnisproblemen als auch sonst gut helfen.
Man muss die Tools auch nicht zum "Vibe Coding" benutzen (geht natürlich auch, ist für FHEM aber eher so semi-empfehlenswert), sondern kann das auch einfach als Google-Translate auf Steroiden verstehen und allein zum Erklären nutzen.

Vielleicht wäre das eine Option für dich? @Marko1976

Zum Beispiel liefert folgender Prompt:

Eigentlich wollte ich nur wissen, was $_ ist und in der Dokumentation steht das:

Code Auswählen Erweitern

$_
The default input and pattern-searching space. The following pairs are equivalent:

while (<>) {...}    # equivalent only in while!
while (defined($_ = <>)) {...}

/^Subject:/
$_ =~ /^Subject:/

tr/a-z/A-Z/
$_ =~ tr/a-z/A-Z/

chomp
chomp($_)
Here are the places where Perl will assume $_ even if you don't use it:

The following functions use $_ as a default argument:
abs, alarm, chomp, chop, chr, chroot, cos, defined, eval, evalbytes, exp, fc, glob, hex, int, lc, lcfirst, length, log, lstat, mkdir, oct, ord, pos, print, printf, quotemeta, readlink, readpipe, ref, require, reverse (in scalar context only), rmdir, say, sin, split (for its second argument), sqrt, stat, study, uc, ucfirst, unlink, unpack.
All file tests (-f, -d) except for -t, which defaults to STDIN. See "-X" in perlfunc
The pattern matching operations m//, s/// and tr/// (aka y///) when used without an =~ operator.
The default iterator variable in a foreach loop if no other variable is supplied.
The implicit iterator variable in the grep() and map() functions.
The implicit variable of given().
The default place to put the next value or input record when a <FH>, readline, readdir or each operation's result is tested by itself as the sole criterion of a while test. Outside a while test, this will not happen.
$_ is a global variable.

However, between perl v5.10.0 and v5.24.0, it could be used lexically by writing my $_. Making $_ refer to the global $_ in the same scope was then possible with our $_. This experimental feature was removed and is now a fatal error, but you may encounter it in older code.

Mnemonic: underline is understood in certain operations.
Ich verstehe das nicht, das ist viel zu kompliziert

Diese Antwort:

Alles klar 🙂 — lass mich das mal runterbrechen.
$_ in Perl wirkt am Anfang wirklich verwirrend, ist aber eigentlich eine Abkürzung für "die Standardvariable".

Man kann sich das so vorstellen: wenn du in Perl etwas machst, ohne zu sagen "mit welcher Variable?", dann nimmt Perl automatisch $_.


Beispiel 1: String-Bearbeitung

Code Auswählen Erweitern

perl
$_ = "hallo welt";
tr/a-z/A-Z/;  # wandelt $_ in Großbuchstaben
print $_;      # HALLO WELT
Ohne $_ müsstest du schreiben:

Code Auswählen Erweitern

perl
$_ = "hallo welt";
$_ =~ tr/a-z/A-Z/;
print $_;

Beispiel 2: Pattern-Matching

Code Auswählen Erweitern

perl
$_ = "Subject: Test";
if (/^Subject:/) {  # prüft automatisch $_
    print "Hat Betreff\n";
}
Das ist dasselbe wie:

Code Auswählen Erweitern

perl
if ($_ =~ /^Subject:/) {
    print "Hat Betreff\n";
}

Beispiel 3: while (<>)

Code Auswählen Erweitern

perl
while (<>) {
    chomp;      # meint: chomp($_)
    print "$_\n";
}
Hier liest Perl zeilenweise von STDIN oder einer Datei in $_ ein.
Also: jede neue Zeile landet automatisch in $_.


Beispiel 4: foreach

Code Auswählen Erweitern

perl
foreach (1..3) {
    print "Nummer $_\n";
}
Ohne dass du eine Variable angibst, nimmt Perl $_ als Schleifenvariable.


Wichtigste Punkte:

• $_ ist die Default-Variable in vielen Situationen.
• Wenn du nichts anderes sagst, landen Sachen in $_.
• Manchmal spart das viel Schreibarbeit, weil du dir $_ =~ ... sparen kannst.
• Aber es kann auch unübersichtlich sein, deswegen benutzen viele lieber explizite Variablen.

👉 Kurz gesagt:
$_ ist in Perl der automatische Platzhalter für "das Ding, das gerade gemeint ist".


Soll ich dir mal ein kleines Mini-Perl-Skript schreiben, das zeigt, wo überall $_ automatisch benutzt wird?

[Marko1976]

Hallo @passibe,
ja das mit den AI's muss ich mir echt mal angewöhnen. Ich schätze ich habe da einfach zu viel Hemmung aufgrund meines Alters. Ich wäre auch nie auf die Idee gekommen, so eine (umfangreiche) Frage zu posten, da ich gelernt habe genau das Gegenteil zu tun - kurz, bündig und so einfach wie möglich. Schätze da haben sich die Zeiten wohl geändert.
Die Beispiele machen es für mich tatsächlich anschaulicher. Bin eh mehr der Typ "Learning by Doing". Da ich ein solches Verfahren aber aus keiner mir bekannten Programmiersprache kenne ist es deshalb nicht wirklich sinnvoller. Egal in welcher Sprache, es muss eigentlich immer jede Variable fest delariert sein bevor man sie benutzen kann. Alleine die Frage was passiert wenn man zb zwei Variablen gleichzeitig in einer Schleife hat - welche wird dann von $_ benutzt, macht die Benutzung für mich eher sinnfrei. Auch davon abgesehen, dass man später nicht zwingend nachverfolgen kann was man irgendwann mal programmiert hat.

Aber es tut gut festzustellen, dass ich nicht der einzige bin, der sich mit dieser Art Dokumentation schwer tut. Das Ding mit @betateilchen ist ja wie fast jedesmal ausgeartet weil er sich partou nicht vorstellen kann, das es Menschen gibt, die nicht Jahrelang mit Perl arbeiten und alle Grundlagen in und auswendig können. So kommt es jedenfalls immer wieder bei mir an auch wenn er anderes behauptet. Ich finde es schade das er so festgefahren ist da er anscheinend echt was auf dem Kasten hat.

Im Prinzip ist die Frage ja geklärt und eine Lösung gefunden.

Das einzige was mich wundert ist, dass es offenbar keine Möglichkeit gibt ein Leerzeichen oder andere Sonderzeichen/Steuerzeichen zu kaschieren. Das ist ja in praktisch jeder Programmiersprache möglich.

[passibe]

Egal in welcher Sprache, es muss eigentlich immer jede Variable fest delariert sein bevor man sie benutzen kann.

Naja, sie ist ja definiert, nur halt implizit und nicht (nochmal) explizit in deinem code. Ist, glaube ich, ähnlich wie $@ in bash.

Aber freut mich, dass das etwas geholfen hat. Viel Erfolg weiterhin!

[Prof. Dr. Peter Henning]

Hier wird von dem TE Kritik an FHEM und den FHEM-Entwicklern geäußert, die man nicht unwidersprochen stehen lassen kann

Fangen wir mal hinten an: Wer schon mehrere Programmiersprachen "kennt", sollte überhaupt keine Schwierigkeiten mit Perl haben. 2006 habe ich genau für diese Zielgruppe mit einem Kollegen zusammen das "Handbuch Programmiersprachen" geschrieben, in dem wir mehr als 20 verschiedene Programmiersprachen kurz und bündig dargestellt haben. Auch das zugehörige Taschenbuch ist leider vergriffen, also mache ich mir den Spaß und stelle das Perl-Kapitel (das ich sogar selbst verfasst habe) hier im Anhang zur freien Verwendung zur Verfügung. Bei Verwendung an anderer Stelle bitte angeben: Henning, P, Vogelsang, H: Handbuch Programmiersprachen (Hanser, 2006). Das habe ich übrigens schon vor Jahren getan, die Datei fliegt hier im FHEM-Forum irgendwo herum. Die Literaturhinweise sind nach 19 Jahren zwar nicht mehr ganz aktuell, aber jeder Interessierte findet auch heute noch deutschsprachige (!) Handbücher zu Perl.

Weiter zum Thema $_: Man kann auch ganz ohne dieses Konstrukt auskommen. Wenn man nicht verstanden hat, warum es kürzere und effizientere Programme ermöglicht, sollte man sich aber irgendwelche Kommentare wie "sinnfrei" verkneifen.

Weiter zum Thema $name: Es ist einfach falsch, dass dies ein "Platzhalter für den Device-Namen ist". Diesen Bezeichner kann man für alles mögliche verwenden, das hängt nämlich von der Definition ab.

Weiter zum Thema

Das einzige was mich wundert ist, dass es offenbar keine Möglichkeit gibt ein Leerzeichen oder andere Sonderzeichen/Steuerzeichen zu kaschieren. Das ist ja in praktisch jeder Programmiersprache möglich.

Auch das ist falsch, selbstverständlich geht das in Perl. Und nein, es heißt nicht "kaschieren".

Weiter zum Thema

Ob man Fhem als Programm bezeichnen sollte ist in meinen Augen fraglich.

Das ist, deutlich gesagt, granatenmäßiger Unsinn. fhem.pl ist das zentrale FHEM-Programm, und das ist beileibe keine "Ansichtssache".

Weiter zum Thema

Ich sehe es eher als Sammelsorium verschiedener Einzelprogramme.

Auch das ist Unsinn. In nahezu jeder Programmiersprache gibt es das Konzept einzelner Module, die im Bedarfsfall dazu geladen werden.

Ich meine nur das selbst OpenSource-Programme bessere und gleichere Programmstrukturen aufweisen als Fhem wo man sehr, sehr oft merkt, das verschiedene Leute mit verschiedenen Filosophien etwas geschrieben haben.

Das ist nicht nur granatenmäßiger, sondern geradezu himmelschreiender Unsinn. Ich schreibe und veröffentliche Open Source Software seit 1986, und habe etliche Artikel über die gesellschaftlichen und technischen Aspekte der Open Source-Bewegung geschrieben. Ein Zitat meiner eigenen Artikel verkneife ich mir, aber wirklich jeder, der sich mit quelloffener Software befasst, sollte den berühmten Artikel "The Cathedral and the Bazaar" von Eric S. Raymond aus dem Jahr 1997 kennen. Hier eine Übersetzung ins Deutsche: https://web.archive.org/web/20211026213655/https://www.selflinux.org/selflinux/html/die_kathedrale_und_der_basar.html

Und um auch das klar zu sagen: FHEM genügt in jeder Hinsicht dem Entwicklungsmodell, das für ganz faule auch auf der Wikipedia-Seite https://de.wikipedia.org/wiki/Die_Kathedrale_und_der_Basar zusammengefasst ist.

Bei Fhem kommt man um Perl nicht herum, es ist kein Tool der Programmierer sondern der Anwender wird leider gezwungenermaßen zum Programmierer.

Falsch. FHEM hat eine eigene und sehr einfache Skriptsprache, und die allermeisten Anwender verwenden diese, ohne auf die Perl-Ebene herunterzusteigen.

denn sowohl die Perl- als auch die Fhem-Dokumente sind oft so grottig geschrieben, dass ein Legasteniker wahrscheinlich weniger Probleme hat damit klar zu kommen

Das zeugt zunächst einmal von Unwissenheit des TE darüber, wie Software dokumentiert ist. Nämlich nicht für Unwillige, sondern als Hilfe zur Selbsthilfe. Den zweiten Teil dieser erneuten Beleidigung der FHEM-Entwickler muss man glaube ich nicht verstehen, abgesehen davon, dass es "Legastheniker" heißt.

Schließlich begründet der TE sein Unverständnis von Perl mit persönlichen Problemen.

1."Augenprobleme": Ich habe unter meinen Studenten immer wieder sehgeschädigte Personen gehabt, für die wir früher Aufgaben und Skripte sogar in Braille übersetzt haben. Im Zeitpunkt der Screen-Reader ist das aber vollkommen aus der Mode gekommen, ich kann ganz sicher sagen, dass heute sehgeschädigte Personen einen weitestgehend barrierefreien Zugang zur Informatik finden, wenn sie das wollen.

2."Alter": Dieses Mimimi sollte man wirklich unterlassen, denn der weitaus größte Teil der FHEM-Entwickler ist deutlich jenseits des 40. Lebensjahrs. Auch als ausgewiesener Bildungsexperte kann ich klar sagen, dass das Erlernen neuer Kenntnisse und Fähigkeiten auch im hohem Alter möglich ist. Und mit "fast 50" ganz sicher nur eine Frage des Wollens ist.

Zusammengefasst möchte ich dem TE _dringend_ empfehlen, sich an den 7. Satz aus dem "Tractatus logico-philosophicus" von Ludwig Wittgenstein zu halten.

LG

pah

[andies]

Also wir haben das Thema erstmal geschlossen, bis sich die Gemüter beruhigt haben. Leider gibt es seit einiger Zeit ein Software-Problem, so dass die Moderatoren untereinander nur mühsam bis gar nicht die Dinge, die gerade passieren, besprechen können. Ein weiterer Grund, warum sich alle bitte gedulden.