!eigenartigSpezifisch
ich_iel
Die offizielle Zweigstelle von ich_iel im Fediversum.
Alle Pfosten müssen den Titel 'ich_iel' haben, der Unterstrich darf durch ein beliebiges Symbol oder Bildschriftzeichen ersetzt werden. Ihr dürft euch frei entfalten!
📱 Empfohlene Schlaufon-Applikationen für Lassmich
Befreundete Kommunen:
Sonstiges:
Regeln:
1. Seid nett zueinander
Diskriminierung anderer Benutzer, Beleidigungen und Provokationen sind verboten.
2. Pfosten müssen den Titel 'ich_iel' oder 'ich iel' haben
Nur Pfosten mit dem Titel 'ich_iel' oder 'ich iel' sind zugelassen. Alle anderen werden automatisch entfernt.
Unterstrich oder Abstand dürfen durch ein beliebiges Textsymbol oder bis zu drei beliebige Emojis ersetzt werden.
3. Keine Hochwähl-Maimais oder (Eigen)werbung
Alle Pfosten, die um Hochwählis bitten oder Werbung beinhalten werden entfernt. Hiermit ist auch Eigenwerbung gemeint, z.b. für andere Gemeinschaften.
4. Keine Bildschirmschüsse von Unterhaltungen
Alle Pfosten, die Bildschirmschüsse von Unterhaltungen, wie beispielsweise aus WasistApplikaton oder Zwietracht zeigen, sind nicht erlaubt. Hierzu zählen auch Unterhaltungen mit KIs.
5. Keine kantigen Beiträge oder Meta-Beiträge
ich_iel ist kein kantiges Maimai-Brett. Meta-Beiträge, insbesondere über gelöschte oder gesperrte Beiträge, sind nicht erlaubt.
6. Keine Überfälle
Wer einen Überfall auf eine andere Gemeinschaft plant, muss diesen zuerst mit den Mods abklären. Brigadieren ist strengstens verboten.
7. Keine Ü40-Maimais
Maimais, die es bereits in die WasistApplikation-Familienplauderei geschafft haben oder von Rüdiger beim letzten Stammtisch herumgezeigt wurden, sind besser auf /c/ichbin40undlustig aufgehoben.
8. ich_iel ist eine humoristische Plattform
Alle Pfosten auf ich_iel müssen humorvoll gestaltet sein. Humor ist subjektiv, aber ein Pfosten muss zumindest einen humoristischen Anspruch haben. Die Atmosphäre auf ich_iel soll humorvoll und locker gehalten werden.
9. Keine Polemik, keine Köderbeiträge, keine Falschmeldungen
Beiträge, die wegen Polemik negativ auffallen, sind nicht gestattet. Desweiteren sind Pfosten nicht gestattet, die primär Empörung, Aufregung, Wut o.Ä. über ein (insbesonders, aber nicht nur) politisches Thema hervorrufen sollen. Die Verbreitung von Falschmeldungen ist bei uns nicht erlaubt.

Bitte beachtet auch die Regeln von Feddit.org
Und ich bleibe dabei! Wenn reguläre Ausdrücke die Lösung zu deinem Problem sind, dann ist dein Problem falsch!
Ich finde Reguläre ausdrücke einfach nur ein ziemlich angenehmes Mittel um Text zu verarbeiten.
Mein Problem ist es schnell und einfach HTML zu scrapen und parsen.
Die Lösung? curl "$URL" | grep -E "$REGEX" | sed 's|"$OLD"|"$NEW"|' offensichtlich!
(Keine Sorge, es ist etwas "schöner". Hier ein wunderschöner Ausschnitt:)
Äußerst legitime Anwendung von Regex die ich tatsächlich so eingebaut habe
old_file=$(find . -maxdepth 1 -regextype egrep -regex '\./'"$filename"' [0-9]{4}-[0-9]{2}-[0-9]{2}\..*' -print | sort | tail -n1 | sed 's|\./||')
Dokumentation wäre hierfür überflüssig.

~~Vor 3 Jahren~~ Letzte Woche
Wenn mein Problem ist, dass ich in einer Datei einen häufigen regelmäßig geformten Ausdruck finden und durch einen anderen ersetzen will?
Ein Beispiel wäre anpassen von Skripten nach einer Datenbankmigration um die Schemata und Tabellenamen anzupassen (ja, die neue Datenbank hat Tabellenamen verändert).
Dann brauchst du keine regulären Ausdruck, sondern musst Token ersetzen. Da reicht Pattern-Matching.
Bzw. verwenden deine Skripte zu viele hart-codierte Strings.
Bzw. verwenden deine Skripte zu viele hart-codierte Strings.
Ja, es ist viel besser, dem seltenen Fall, dass sich Tabellennamen ändern, dadurch zu begegnen, indem man seine Tabellennamen in Konstanten auslagert. Das führt garantiert nicht zu Aneurysmen, glaub mir.
const SQL = `SELECT ${CUSTOMER_TABLE_NAME_COLUMN} FROM ${CUSTOMER_TABLE_NAME} JOIN ${TARIFF_TABLE_NAME} USING (${CUSTOMER_TABLE_ID_COLUMN);`
Deine Unfähigkeit, prepared Statements zu verwenden, ist jetzt aber ein Du-Problem.
Vielleicht hast du bessere Prepared Statements als ich. In meinen kann ich nicht den Tabellennamen konfigurierbar machen.
Da der Tabellen-Name ein nur von dir kontrollierter Wert ist, kannst du ihn mittels String-Concatination in dein prepared Statement einbauen, um danach die Variablen zu ersetzen.
Kann es sein, dass du den Kontext vergessen hast? Bei luciferofastora ging es um
anpassen von Skripten nach einer Datenbankmigration um die Schemata und Tabellenamen anzupassen
worauf du „zu viele hart-codierte Strings“ und später „Prepared Statements” geantwortet hast.
Das kann sein. Ich bin gestern hochgefiebert und habe Dinge für gut befunden, die so keinen Sinn ergeben.
Dann brauchst du keine regulären Ausdruck, sondern musst Token ersetzen. Da reicht Pattern-Matching.
Das sagt mir nichts, fürchte ich, aber ich lass mich gerne belehren.
Bzw. verwenden deine Skripte zu viele hart-codierte Strings.
Ich geh schon bei jeder Gelegenheit her und isolier alle Folgeabfragen gegen die ursprünglichen Quellen. Die jeweiligen Tabellen werden genau einmal direkt bezeichnet, danach haben sie ein Alias, gerade um so was zu minimieren. (Und weil die ursprünglichen Bezeichnungen beschissen sind, keine Ahnung was die Entwickler da geritten hat. Gleiches Spiel mit den Spalten.)
Hilft halt nix, wenn ich insgesamt 100 verschiedene Tabellen abfrag, die jeweils irgendwo in Konstanten auszulagern. Das Schema, ja, hätte ich können wenn ich geahnt hätte, dass die das umstrukturieren, wäre aber auch nicht das Problem gewesen.
Aber dass sie das Namensschema durch die Bank ändern, das war nicht angekündigt oder auch nur zu ahnen.
Mein Beileid.
Wie parst du denn eine Nutzereingabe eines Datumsbereichs?
Abhängig von der Sprache mit Parser-Kombinatoren (megaparsec :: Haskell, nom: Rust) Paketen oder der Standardbibliothek (java DateFormat).
Irgendwas das auf ICU basiert (oder in C++ direkt ICU). Den Text zu Zahlen zu machen ist ja nur die halbe Miete, irgendwie muss auch noch ein Zeitpunkt daraus werden. https://unicode-org.github.io/icu/userguide/format_parse/datetime/
Den Text zu Zahlen zu machen, ist der schwerere Teil. Sobald ich eine Angabe für jeden der Datumsteile habe, ist es ein Leichtes, daraus das Datum zu bauen.
Der Rest geht auch an @VegOwOtenks@lemmy.world:
Mein Anwendungsfall wird ist eine Webseite. Ich will nicht für ein einzelnes Eingabefeld einen Compiler mitliefern, der rekursive Sprachen parsen kann. Ich habe mich schon nach Libraries umgeschaut, aber was ich gefunden habe, entsprach nicht den Anforderungen. Die meisten parsen nur einzelne Datumse (bei mir geht’s um einen Datenbereich) und ich will möglichst reibungsarm in dem sein, was ich von Nutzern akzeptiere. Die Libraries, die ich gefunden habe, sind eher strikt in dem, was sie als gültige Eingabe akzeptieren.
Beispiel: Mit meinem selbstgebastelten Regex kann ich die Eingabe 'w' als '2026-01-12/2026-01-18' interpretieren; '8.' als '2026-01-08/2026-01-08' und '12.25' als '2025-12-01/2025-12-31'.
Muss das so flexibel sein? Nein. Aber für die Power-User wird das hoffentlich sehr angenehm zu bedienen sein.
Datumse
HLI, dass die Informatik mein "Meinst du Daten oder Daten"-Problem bereits gelöst hat.
Habe auch schon „Datümer” gehört.
Find ich noch besser, versuche die Übernahme ins Vokabular.
(Suche eben ergab, dass die Quellen, die Richtigkeit für sich beanspruchen, zu feige sind, ein offensichtliches Manko der deutschen Sprache zu bereinigen. Schwach.)
Ah verstehe, für Datenintervalle weiß ich auch nichts vorgebautes.
Die Abkürzungen klingen praktisch, cool... und verwirrend. :]]
verwirrend
Auf jeden Fall, keine Frage. Ich hoffe, dass Standardnutzer sich eher an Standardangaben halten, die eher explizit sind und deshalb auch eher erwartungsgemäß verarbeitet werden. Und wer tiefer unter die Haube guckt, findet, dass er sich für die eher erwarteten Anwendungsfälle einige Tastendrücke sparen kann.
Ich glaube, ich versuche gerade mehr, mich zu überzeugen als dich.
Mein Problem ist eine reguläre Sprache mit beliebigem Alphabet kurz mit Text zu beschreiben, was schlägst du vor?
Ist ein sehr akademisches Problem aus dem Elfenbeinturm. Deswegen falsch.
Auch wieder wahr
Ein einziger regulärer Ausdruck, der ein ganzes Buch füllt. O_o
~und~ ~ein~ ~bisschen~ ~Logik~ :D