Hierzu wollte ich noch was schreiben ...
Huo hat geschrieben: 25.05.2022 01:43:36
4) Schreibe die entsprechenden Intervallausdruecke fuer die drei anderen Quantoren: * + ?
* -> {0,} oder {,}
Die Form `{,}' ist unportabel, weder POSIX noch Henry Spencers regex-Lib beschreiben sie als erlaubt (auch wenn sie vielleicht trotzdem funktioniert).
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04_06 hat geschrieben:
When an ERE matching a single character or an ERE enclosed in parentheses is followed by an interval expression of the format "{m}", "{m,}", or "{m,n}", together with that interval expression it shall match what repeated consecutive occurrences of the ERE would match. The values of m and n are decimal integers in the range 0 <= m<= n<= {RE_DUP_MAX}, where m specifies the exact or minimum number of occurrences and n specifies the maximum number of occurrences. The expression "{m}" matches exactly m occurrences of the preceding ERE, "{m,}" matches at least m occurrences, and "{m,n}" matches any number of occurrences between m and n, inclusive.
Manpage regex(7) hat geschrieben:
A bound is '{' followed by an unsigned decimal integer,
possibly followed by ',' possibly followed by another
unsigned decimal integer, always followed by '}'.
Huo hat geschrieben: 25.05.2022 01:43:36
5) Erklaere die RE: `**'. Auf was wird sie matchen?
Uff! Meine erste Vermutung: Der erste Stern wird literal interpretiert, da nichts vor ihm steht, der zweite Stern hingegen als Quantor. Die RE "sollte" also auf beliebig viele aufeinander folgende Sterne matchen, einschließlich null Sterne.
grep -o '**' hält sich auch schön brav an meine Vermutung, nicht jedoch
egrep -o '**', das nichts ausgibt.
Zweite Vermutung: Der erste Stern wird als Quantor auf den
leeren String angewendet. Der zweite Stern ist dann redundant, also verzichtbar. Im Grunde ist sogar der erste Stern verzichtbar, da sowohl die mehrmalige Wiederholung als auch das Weglassen eines leeren (!) Strings sinnlos ist. Diese Hypothese wird dadurch bestätigt, dass egrep '**' alle Zeilen eines Textes ausgibt (der leere String ist halt Teilmenge aller Zeilen), egrep
-o '**' jedoch nichts (weil es keine passenden nicht leeren Teile gibt, die ausgegeben werden könnten). Das gleiche Verhalten zeigt egrep für die REs
'*' und
'' (leere RE).
Bezugnehmend auf deine Anmerkung zu den theoretischen Aufgaben beim Teil 07 koennte ich hier nun sagen, dass das auch so eine Aufgabe war: damit ihr darueber nachdenkt, was sein koennte und prueft was ist und wozu man das brauchen koennte. (Oder ich bekenne, dass ich gar nicht so weit gedacht habe, sondern die Aufgabe einfach mal gestellt habe ohne schon die Antwort im Kopf gehabt zu haben.
)
Die Antwort jedenfalls findet man wenn man einen Blick in POSIX wirft
:
Der Fall ist also nicht definiert. Was passiert haengt davon ab welche Implementierung man verwendet.
Vielleicht motiviert das auch nochmal dazu, nun, wo wir alle Aspekte von EREs erkundet haben, ab und an mal einen Blick in POSIX zu werfen wenn ihr euch mit solchen schwierigeren Fragen befasst.
Huo hat geschrieben: 25.05.2022 01:43:36
Matche den Inhalt eines Single-Quoted Strings (dieser kann das Single-Quote nicht enthalten).
Es werden allerdings die Single Quotes mit gematcht. Einen Regulären Ausdruck, der nur den String
innerhalb der Quotes matcht, habe ich nicht gefunden (vielleicht gar nicht möglich?).
Du hast recht, dass es mit EREs nicht moeglich ist den Inhalt eines gequoteten Strings zu matchen *ohne* die Quotes. Mit Lookaheads und Lookbehinds von PCREs ist das moeglich.
Btw: Waehrend es bei einzeichigen Endemarkern (wie bei Quotes) mit einer invertierten Zeichenklasse gearbeitet werden kann, um zwei quoted Strings auf einer Zeile separat zu matchen, geht das bei einem mehrzeichigen Endmarker (wie bei ``ENDE'') so nicht:
Code: Alles auswählen
:-Q echo "xxx 'foo' xxx 'bar' xxx" | egrep -o "'[^']+'"
'foo'
'bar'
:-Q echo "xxx STARTfooENDE xxx STARTbarENDE xxx" | egrep -o "START.+ENDE"
STARTfooENDE xxx STARTbarENDE
Huo hat geschrieben: 25.05.2022 01:43:36
11) Finde ein sinnhaftes Praxisbeispiel fuer eine RE mit Punkt aber ohne Quantoren.
Ein wirklich sinnhaftes natürlichsprachiges Beispiel ist m.E. nicht möglich wegen der Beliebigkeit, die der Punkt repräsentiert. Man könnte aber mit
nach doppelt gequoteten Strings suchen, die genau ein Zeichen umfassen – etwa in einem Text, der einzelne so gequotete Zeichen erklärt, definiert oder kodiert ...
Ihr habt schon recht, dass man meist etwas Definierteres als den Punkt verwenden wollen wuerde, allerdings verwende ich in der Praxis oft genug sowas:
... um alle Ueberschriften in einem HTML-Dokument rauszusuchen. (Natuerlich waere XPath korrekter, aber oft will ich es nur ganz kurz mal sehen und der unperfekte Aufruf von egrep mit dem Punkt ist das was fuer mich am schnellsten funktioniert.)
Auch kann man mit dem Punkt alle einbuchstabigen HTML-Tags suchen:
oder alle literalen chars in C:
Bei wenigen Wiederholungen tippe ich lieber mehrere Punkte als geschweifte Klammern weil sich das schneller tippen laesst, z.B.:
... um alle vierbuchstabigen Woerter aus dem Woerterbuch auszugeben.
Auch wenn Punkte meist vor Quantoren stehen, so koennen sie auch ohne Quantoren sinnvoll sein.
(Btw: Bei BREs, die kein Plus haben, realisiert man `.+' mittels `..*' -- der erste Punkt hat hier auch keinen Quantor.)