Was ein netter Nachmittag mit Kokain und Programmieren werden sollte, ist zu zwei Tagen Arbeit ausgeartet. Und der schlimmste Teil war, die Benutzerdoku zu schreiben!
Ein einziger regulärer Ausdruck, der ein ganzes Buch füllt. O_o
und ein bisschen Logik :D
!eigenartigSpezifisch
Und ich bleibe dabei! Wenn reguläre Ausdrücke die Lösung zu deinem Problem sind, dann ist dein Problem falsch!
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.
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.
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.
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 JahrenLetzte Woche
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
