grep und regexp

[Andreas Neumann]

Hallo,

ich hatte kürzlich die Aufgabe, ein kleines Textfile auf bestimmte Anzahl
der Zeichen zu prüfen. Hab's schließlich mit wc -m gelöst.
Das müsste doch auch per grep und Regular Expression gehen? Ich finde den
Weg nicht. Wie müsste das aussehen, wenn ich z.B. feststellen will ob die
Datei genau 12 beliebige Ziffern enthält?
Ist eine akademische Frage, meine Aufgabenstellung ist ja schon gelöst.
Interessieren würde es mich trotzdem.

[Stefan Wiens]

grep '^[[:digit:]]\{12\}$'

Das testet natürlich nicht auf die "Datei",
sondern auf Zeilen, für die das Suchmuster
passt.

--
Stefan

[Stefan Wiens]

Geht es dir um Ziffern, Zeichen oder Bytes?

--
Stefan

[Axel Reichert]

Andreas Neumann <nn...@postheo.de> writes:

> ich hatte kürzlich die Aufgabe, ein kleines Textfile auf bestimmte Anzahl
> der Zeichen zu prüfen. Hab's schließlich mit wc -m gelöst.

"-m" kannte ich nicht, wohl aber "-c".

$ wc -m README.md
11827 README.md
$ wc -c README.md
11894 README.md
$ ls -l README.md
-rw-r--r-- 1 axel axel 11894 Jan 15 13:31 README.md

Differenz vermutlich wegen UTF-8 und Umlauten, egal.

> Das müsste doch auch per grep und Regular Expression gehen?

Du muesstest erst eine Zeile daraus machen:

$ printf "a\nb" | tr '\n' ' ' | grep -Ec '^.{2}$'
0
$ printf "a\nb" | tr '\n' ' ' | grep -Ec '^.{3}$'
1
$ printf "a\nb" | tr '\n' ' ' | grep -Ec '^.{4}$'
0

Tschoe!

Axel

[Stefan Wiens]

Axel Reichert <ma...@axel-reichert.de> writes:

> Andreas Neumann <nn...@postheo.de> writes:
>
>> ich hatte kürzlich die Aufgabe, ein kleines Textfile auf bestimmte Anzahl
>> der Zeichen zu prüfen. Hab's schließlich mit wc -m gelöst.
>
> "-m" kannte ich nicht, wohl aber "-c".
>
> $ wc -m README.md
> 11827 README.md
> $ wc -c README.md
> 11894 README.md
> $ ls -l README.md
> -rw-r--r-- 1 axel axel 11894 Jan 15 13:31 README.md
>
> Differenz vermutlich wegen UTF-8 und Umlauten, egal.

Das ist nicht egal, denn die Ausgabe hängt von der locale ab.

--
Stefan

[Markus Schaaf]

Am 23.02.23 um 13:44 schrieb Stefan Ram:

> Um zu zählen, ob eine Datei genau zwölf Ziffern enthält,
> kann man beispielsweise ein kleines Programm in Python
> schreiben.
>
> import re as _re
> import sys as _sys
>
> with open( 'file' )as stream:
> count = 0
> while True:
> c = stream.read( 1 )
> if c:
> if _re.match( r'\d', c ): count += 1
> else:
> break
> result = count != 12
> _sys.exit( result )
>
> Für größere Dateien läßt sich das leicht auch entsprechend
> in C schreiben.

Pah, python!

perl -ne '$s++ while /\d+/g; END{ print "$s\n" }' < file

[Andreas Neumann]

Axel Reichert wrote:

> Andreas Neumann <nn...@postheo.de> writes:
>
>> ich hatte kürzlich die Aufgabe, ein kleines Textfile auf bestimmte Anzahl
>> der Zeichen zu prüfen. Hab's schließlich mit wc -m gelöst.
>
> "-m" kannte ich nicht, wohl aber "-c".

Ist in meinem Fall gleichwertig.
$ cat Datei.txt
12345678 0
$ wc -c Datei.txt
12
$ wc -m Datei.txt
12

> Du muesstest erst eine Zeile daraus machen:

So weit war ich garnicht, es steht sowieso alles in einer Zeile, hier 2
Zahlen per Space getrennt.
Somit funktioniert auch ein
$ grep -Ec '^.{10}$' Datei.txt
1

Nach Ersetzen des Newline matcht er allerdings auf 12 Zeichen:
cat Datei.txt | tr '\n' ' ' | grep -Ec '^.{12}$'
1

Mir ist allerdings nicht klar warum es nach Ersetzung 12 sind. Da muss ich
mal in mich gehen. Zählt Newline für 2 Zeichen?

Das Beispiel von Stefan bekomme ich überhaupt nicht zum Laufen.

Vielen Dank!

[Marcel Logen]

Andreas Neumann in de.comp.os.unix.shell:

>Axel Reichert wrote:
>> Andreas Neumann <nn...@postheo.de> writes:

>>> ich hatte kürzlich die Aufgabe, ein kleines Textfile auf bestimmte Anzahl
>>> der Zeichen zu prüfen. Hab's schließlich mit wc -m gelöst.
>>
>> "-m" kannte ich nicht, wohl aber "-c".
>
>Ist in meinem Fall gleichwertig.

In Deiner Datei kommen keine Multi-Byte-Zeichen vor.

>$ cat Datei.txt
>12345678 0
>$ wc -c Datei.txt
>12
>$ wc -m Datei.txt
>12

Ich vermute, das Zeilenende ist hier nicht LF ("\n"),
sondern CRLF ("\r\n"). Das sind zwei Bytes.

Was sagt denn bei Dir dieser Befehl?

od -An -tx1c Datei

Marcel
--
╭─╮ ╭─╮ ╭──╮ ╭───────╮ ╭────╮ ╭───────────╮ ╭─╮ ..67..
╭──╯ ╰─╯ ╰─╯ ╰─╯ ..21..╰───╯ ╭─╯ ╰───────╮ ╰──╮ │ │ ╭───╮ ╭─╮
╰─╮ ..24..╭───╯ ╭──╮ │ ╭───╯ │ ╰─╯ │ │ ╰
────╯ ╰───────╯ ╰─────╯ ╰───────╯ ..60..╰───╯

[Marcel Logen]

Andreas Neumann in de.comp.os.unix.shell:

>Axel Reichert wrote:
>> Andreas Neumann <nn...@postheo.de> writes:

>>> ich hatte kürzlich die Aufgabe, ein kleines Textfile auf bestimmte Anzahl
>>> der Zeichen zu prüfen. Hab's schließlich mit wc -m gelöst.
>>
>> "-m" kannte ich nicht, wohl aber "-c".
>
>Ist in meinem Fall gleichwertig.

In Deiner Datei kommen keine Multi-Byte-Zeichen vor.

>$ cat Datei.txt
>12345678 0
>$ wc -c Datei.txt
>12
>$ wc -m Datei.txt
>12

Ich vermute, das Zeilenende ist hier nicht LF ("\n"),
sondern CRLF ("\r\n"). Das sind zwei Bytes.

Was sagt denn bei Dir dieser Befehl?

od -An -tx1c Datei.txt

Marcel

[supersedes wg. Fehlers]
--
│ ╭─╮ ╭─────╮ ╭───╮ ╭───────╮ ╭──╮ ╭──╮ ..66..╭
╰─╯ ╰───╮ ╰──╮ ╰─╮ ╰─╮ │ ╭──╯ │ │ ╰─╯ ╰─╮ ..64..╭─╯
...1..╭─╯ ╭─╮ │ ╰─╮ ╭──╯ ╰───╯ ╭───────╯ │ ╭────╯ ╭─╮ ╭─╮ │
╰───╯ ╰─╯ ╰─╯ ..30..╰───────────╯ ╰───────╯ ╰──╯ ╰─╯

[Andreas Neumann]

Marcel Logen wrote:

> Ich vermute, das Zeilenende ist hier nicht LF ("\n"),
> sondern CRLF ("\r\n"). Das sind zwei Bytes.
>
> Was sagt denn bei Dir dieser Befehl?
>
> od -An -tx1c Datei.txt

$ od -An -tx1c Datei.txt
31 32 33 34 35 36 37 38 20 30 0a 0a
1 2 3 4 5 6 7 8 0 \n \n

Zwei Newlines? Da habe ich wohl versehentlich zweimal die Enter-Taste
gedrückt.
od ist ein interessantes Werkzeug, das kannte ich noch nicht.

[Marcel Logen]

Andreas Neumann in de.comp.os.unix.shell:

>ich hatte kürzlich die Aufgabe, ein kleines Textfile auf bestimmte Anzahl
>der Zeichen zu prüfen.

Es sollte die Dateigröße in Bytes festgestellt werden?

> Hab's schließlich mit wc -m gelöst.

Das zeigt die Anzahl der Zeichen an.
"wc -c" wäre für die Anzahl der Bytes.

| user15@o15:/tmp$ cat Datei.txt
| 12345678ß0

| user15@o15:/tmp$ od -An -tx1c Datei.txt
| 31 32 33 34 35 36 37 38 c3 9f 30 0d 0a
| 1 2 3 4 5 6 7 8 303 237 0 \r \n

| user15@o15:/tmp$ wc -c Datei.txt
| 13 Datei.txt

| user15@o15:/tmp$ wc -m Datei.txt
| 12 Datei.txt

>Das müsste doch auch per grep und Regular Expression gehen?

Ich denke, grep ist das flsache Tool dafür.

Ermitteln der Dateigröße geht auch so:

| user15@o15:/tmp$ stat -c '%s' Datei.txt
| 13

Oder vielleicht so:

| user15@o15:/tmp$ ls -l Datei.txt | awk '{print $5}'
| 13

Marcel
--
╭─╮ ╭─╮ ╭──╮ ╭─╮ ╭─╮ ╭────╮ ..63..╭──╯
╯ ╰─╯ │ ╭─╮ ╭──╮ │ ╰─────╮ │ │ ╭───╯ ╰───╯ ╭─╯ ..61..╭─╯
│ │ ╰───╯ │ ╭─╯ ╭─────╯ │ ╰───╯ ..49..╰──╮ ╭───╮ ╰───╮
╰──╯ ╰─╯ ╰─────────╯ ..52..╰─╯ ╰──────╯

[Marcel Logen]

Andreas Neumann in de.comp.os.unix.shell:

>Marcel Logen wrote:

>> Ich vermute, das Zeilenende ist hier nicht LF ("\n"),
>> sondern CRLF ("\r\n"). Das sind zwei Bytes.
>>
>> Was sagt denn bei Dir dieser Befehl?
>>
>> od -An -tx1c Datei.txt
>
>$ od -An -tx1c Datei.txt
> 31 32 33 34 35 36 37 38 20 30 0a 0a
> 1 2 3 4 5 6 7 8 0 \n \n
>
>Zwei Newlines? Da habe ich wohl versehentlich zweimal die Enter-Taste
>gedrückt.

Das hätte man aber beim "cat" sehen müssen:

| user15@o15:/tmp$ cat Datei.txt
| 12345678 0
|
| user15@o15:/tmp$

>od ist ein interessantes Werkzeug, das kannte ich noch nicht.

Ist ähnlich wie hexdump.

Marcel

[Stefan Wiens]

Andreas Neumann <nn...@postheo.de> writes:

> Das Beispiel von Stefan bekomme ich überhaupt nicht zum Laufen.

Du hast von Ziffern gesprochen, aber vielleicht etwas anderes
gemeint.

$ echo 123456789012 | grep '^[[:digit:]]\{12\}$'
123456789012

--
Stefan

[Helmut Waitzmann]

Andreas Neumann <nn...@postheo.de>:

> Wie müsste das aussehen, wenn ich z.B. feststellen will ob die
> Datei genau 12 beliebige Ziffern enthält?

Wenn die Ziffern nur die ASCII‐Ziffern sind (manche Locales
können auch noch andere Ziffern haben), sollte das folgende
funktionieren:

{
# Wirf alles weg, was keine Ziffer ist; die Ziffern
# kopiere in die Standardausgabe:
LC_ALL=C tr -d -C -- '[:digit:]' < die_Datei &&
# Gib zum Schluss ein Zeilenende aus, damit man eine
# vollstaendige Zeile erhaelt:
echo
# Jetzt ist genau eine Zeile uebrig, deren Inhalt alle
# 0 oder mehr Ziffern, als eine Zahl aneinandergereiht,
# ist.
} |
LC_ALL=C grep -E -x -q -- '[[:digit:]]{12}'

Wenn die Datei nur dem augenblicklichen Locale entsprechende
Byte‐Folgen, also keine Byte‐Folgen, die keine gültigen Zeichen
sind, enthält, dann sollte eigentlich

{
# Wirf alles weg, was keine Ziffer ist; die Ziffern
# kopiere in die Standardausgabe:
tr -d -C -- '[:digit:]' < die_Datei &&
# Gib zum Schluss ein Zeilenende aus, damit man eine
# vollstaendige Zeile erhaelt:
echo
# Jetzt ist genau eine Zeile uebrig, deren Inhalt alle
# 0 oder mehr Ziffern, als eine Zahl aneinandergereiht,
# ist.
} |
grep -E -x -q -- '[[:digit:]]{12}'

auch noch gegebenenfalls andere als die ASCII‐Ziffern zählen.  (Der
Unterschied zum vorigen ist nur, dass die
Umgebungsvariablenbelegungen «LC_ALL=C» jeweils weggelassen sind.)

Zumindest auf meinem Debian‐Linux‐System beherrscht «tr» (siehe die
Bedienungsanleitung zur Option «-C») aber keine Multi‐Byte‐Zeichen;
deshalb wird das bei mir scheitern.  Das bedeutet, dass mein «tr»
hier hinter dem POSIX‐Standard
(<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tr.html#top>)
zurückbleibt.

Im Gegensatz zu «tr» kommt «sed» auf meinem System mit
Multi‐Byte‐Zeichen aber zurecht.  Also kann ich die Datei zunächst
mit «sed» putzen, indem ich alles entfernen lasse, was keine Ziffer
und kein Zeilenende ist.  Danach enthält sie nur noch Zeilen, in
denen 0 oder mehr Ziffern stehen.  Die kann ich dann getrost durch
«tr» schieben, um alle Zeilenenden zu entfernen.  Dann kann ich wie
oben verfahren:

{
sed -e 's/[^[:digit:]]//g' -- die_Datei |
tr -d -- '\n' &&
echo
} |
grep -E -x -q -- '[[:digit:]]{12}'

In allen hier angeführten Beispielen – vorausgesetzt, man beachtet
ihre Einschränkungen – gilt:  Der Exit‐Status ist genau dann 0,
wenn die Datei genau 12 Ziffern enthält.

[Peter J. Holzer]

On 2023-02-23 13:13, Markus Schaaf <msc...@elaboris.de> wrote:
> Am 23.02.23 um 13:44 schrieb Stefan Ram:
>
>> Um zu zählen, ob eine Datei genau zwölf Ziffern enthält,
>> kann man beispielsweise ein kleines Programm in Python
>> schreiben.
>>
>> import re as _re
>> import sys as _sys
>>
>> with open( 'file' )as stream:
>> count = 0
>> while True:
>> c = stream.read( 1 )
>> if c:
>> if _re.match( r'\d', c ): count += 1
>> else:
>> break
>> result = count != 12
>> _sys.exit( result )
>>
>> Für größere Dateien läßt sich das leicht auch entsprechend
>> in C schreiben.
>
> Pah, python!

Schlimmer: Ramsches Python.

> perl -ne '$s++ while /\d+/g; END{ print "$s\n" }' < file

perl -nE '$s++ while /\d+/g; END{ say $s }' file

SCNR.

Das macht aber nicht das gleiche wie der Code von Stefan. Das wäre noch
um ein Zeichen kürzer:

perl -nE '$s++ while /\d/g; END{ say $s }' file

hp

[Christian Garbs]

Mahlzeit!

Peter J. Holzer <hjp-u...@hjp.at> wrote:
> On 2023-02-23 13:13, Markus Schaaf <msc...@elaboris.de> wrote:

>> perl -ne '$s++ while /\d+/g; END{ print "$s\n" }' < file
>
> perl -nE '$s++ while /\d+/g; END{ say $s }' file
>
> SCNR.

Wenn Du golfen willst, nimm doch die Leerzeichen raus.

SCNR2
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Deutsche Leitkultur?
Was nutzt es einem Ausländer, der in Deutschland von Dumpfbacken
zusammengeschlagen wird, wenn er Goethes Faust auswendig kennt?

[Thomas Dorner]

r...@zedat.fu-berlin.de (Stefan Ram) writes:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>Mit grep alleine ist es etwas schwierig, weil grep doch im
>>wesentlichen zeilenorientiert ist.
>
> Selbst in regulären Ausdrücken steckt diese Zeilenorientierung
> noch etwas drinnen, wenn man bedenkt, daß "." in der Regel
> keine Zeilenenden umfaßt.
>
> Manchmal kann man dies über eine Option ändern. Ich greife
> dann auch oft zu einem Muster wie "[^`]" oder "[^\001]",
> welches wohl auch Zeilenenden umfaßt (wenn ich glaube, daß
> "`" beziehungsweise "\001" nicht in einem Text vorkommt).

Da wechsele ich in der Regel lieber gleich zu Perl und spendiere meinem
regulären Ausdruck mit '.' die Option 's', das macht das Leben in der
Regel leichter.

(bei besonders langen regulären Ausdrücken und entsprechenden Texten
allerdings dann wiederum nicht, da '.+' oder '.*' gerne die Performance
in den Keller zieht - ich habe da z.B. so einen Testfall mit einem
regulären Ausdruck von über 20 kB, während der Entwicklung hat der mir
bei weniger als der Hälfte der Länge den Test schon auf mindestens 2
Minuten ausgedehnt - da habe ich abgebrochen.)

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

[Peter J. Holzer]

On 2023-02-26 14:39, Thomas Dorner <dcous2302...@spamgourmet.com> wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>>Mit grep alleine ist es etwas schwierig, weil grep doch im
>>>wesentlichen zeilenorientiert ist.
>>
>> Selbst in regulären Ausdrücken steckt diese Zeilenorientierung
>> noch etwas drinnen, wenn man bedenkt, daß "." in der Regel
>> keine Zeilenenden umfaßt.
>>
>> Manchmal kann man dies über eine Option ändern. Ich greife
>> dann auch oft zu einem Muster wie "[^`]" oder "[^\001]",
>> welches wohl auch Zeilenenden umfaßt (wenn ich glaube, daß
>> "`" beziehungsweise "\001" nicht in einem Text vorkommt).
>
> Da wechsele ich in der Regel lieber gleich zu Perl und spendiere meinem
> regulären Ausdruck mit '.' die Option 's', das macht das Leben in der
> Regel leichter.
>
> (bei besonders langen regulären Ausdrücken und entsprechenden Texten
> allerdings dann wiederum nicht, da '.+' oder '.*' gerne die Performance
> in den Keller zieht -

.+ und .* sind greedy. Die versuchen, möglichst viel zu matchen, also
zunächst mal den ganzen String. Wenn der lang ist, kann das dauern ...
Das ist zum Teil auch der Implementation geschuldet: Perl arbeitet mit
Backtracking, das kann zu exponentiell schlechtem Laufzeitverhalten
führen. Echte Regular Expressions kann man immer als deterministischen
endlichen Automaten darstellen, der sich in konstanter Zeit abarbeiten
lässt. Allerdings sind PCRE keine echten RE, sondern eine Erweiterung
davon - ob das da überhaupt theoretisch möglich ist, weiß ich nicht.
Es gibt aber Implementationen, die deutlich besseres Worst-Case-
Verhalten zeigen als die Implementation von Perl.

Dort wo es geht, hilft es oft, .+ bzw. .* durch .+? und .*? (also der
non-greedy Variante) zu ersetzen. Dann fängt Perl mit der kürzesten
Möglichkeit an, und das geht meistens schneller. (Der Worst Case ist
aber glaube ich der gleiche).

Und in vielen Fällen kann man statt . einen spezifischeren Ausdruck
hinschreiben.

hp

[Christian Weisgerber]

On 2023-02-26, Thomas Dorner <dcous2302...@spamgourmet.com> wrote:

> Da wechsele ich in der Regel lieber gleich zu Perl und spendiere meinem
> regulären Ausdruck mit '.' die Option 's', das macht das Leben in der
> Regel leichter.

Da bietet sich pcregrep(1) bzw. pcre2grep(1) an. Das liegt gerne
mal schon rum, weil pcre oder pcre2 als Abhängigkeit für irgendwas
anderes installiert sind.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Thomas Dorner]

Ich glaube nicht, in dem Moment wo Du so Sachen look-ahead, look-behind
und vor allem Rückwärtsbezüge (z.B. '(aa|bb)cc$1') auf vorher gefundenes
erlaubst, bist Du eigentlich bei kontextsensitiven Sprachen und damit
zwei Ebenen höher in der Chomsky-Hierarchie.¹

> Es gibt aber Implementationen, die deutlich besseres Worst-Case-
> Verhalten zeigen als die Implementation von Perl.

Perl ist seit 5.6 (wo ich zum ersten Mal mit Performance-Problemen bei
regulären Ausdrücken zu Kämpfen hatte) aber schon deutlich besser
geworden. Vor meinem aktuellen Monster-RE hatte ich schon lange keine
spürbaren Probleme.

> Dort wo es geht, hilft es oft, .+ bzw. .* durch .+? und .*? (also der
> non-greedy Variante) zu ersetzen. Dann fängt Perl mit der kürzesten
> Möglichkeit an, und das geht meistens schneller. (Der Worst Case ist
> aber glaube ich der gleiche).

Ja, das ist er, da letztlich in beiden Fällen komplettes Backtracking
vorkommen kann. (Und im aktuellen Beispiel hatte ich überall +?. Es
gibt übrigens auch noch ??, aber das habe ich in über 2 Jahrzehnten nur
ein oder zwei Mal benötigt.)

Viele Grüße, Thomas

¹ 94 ist Noam Chomsky inzwischen.

[Thomas Dorner]

Christian Weisgerber <na...@mips.inka.de> writes:

> On 2023-02-26, Thomas Dorner <dcous2302...@spamgourmet.com> wrote:
>
>> Da wechsele ich in der Regel lieber gleich zu Perl und spendiere meinem
>> regulären Ausdruck mit '.' die Option 's', das macht das Leben in der
>> Regel leichter.
>
> Da bietet sich pcregrep(1) bzw. pcre2grep(1) an. Das liegt gerne
> mal schon rum, weil pcre oder pcre2 als Abhängigkeit für irgendwas
> anderes installiert sind.

Interessant, das kannte ich noch nicht. Unterscheidet sich das groß von
einem aktuellen GNU grep mit Option -P? Der verwendet schließlich auch
die libpcre2.

[Christian Weisgerber]

On 2023-02-27, Thomas Dorner <dcous2302...@spamgourmet.com> wrote:

>> Da bietet sich pcregrep(1) bzw. pcre2grep(1) an.
>

> Interessant, das kannte ich noch nicht. Unterscheidet sich das groß von
> einem aktuellen GNU grep mit Option -P? Der verwendet schließlich auch
> die libpcre2.

Ich glaube, ich bin auf pcregrep gestoßen, als ich nach einem
Werkzeug für eine zeilenübergreifende Suche gestöbert habe, und
ggrep konnte das nicht.

[Ulli Horlacher]

Christian Weisgerber <na...@mips.inka.de> wrote:
> On 2023-02-27, Thomas Dorner <dcous2302...@spamgourmet.com> wrote:
>
>>> Da bietet sich pcregrep(1) bzw. pcre2grep(1) an.
>>
>> Interessant, das kannte ich noch nicht. Unterscheidet sich das groß von
>> einem aktuellen GNU grep mit Option -P? Der verwendet schließlich auch
>> die libpcre2.
>
> Ich glaube, ich bin auf pcregrep gestoßen, als ich nach einem
> Werkzeug für eine zeilenübergreifende Suche gestöbert habe, und
> ggrep konnte das nicht.

Deshalb hatte ich vor 30 Jahren fpg geschrieben.

https://fex.belwue.de/fstools/fpg.html


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/