>>>>> sed 's/P_\([0-9][0-9]*\)/\1P/g'
>>>> Kannst Du mir kurz noch erklären, was da abläuft?
>>>> Der erste Teil ist klar, ich suche "P_" plus Zahl.
>>>> Was bewirkt der "*"?
>>> "[0-9]*" : Null oder mehr Ziffern.
>>> "[0-9][0-9]*" : Eine oder mehr Ziffern (eine Zahl).
>> Dafür gibts doch das '+':
>> "[0-9]+" : Eine oder mehr Ziffern (eine Zahl).
> Das gibt es nur bei "extended regular expressions".
Das '+' gibt es auch in den Basic Regular Expressions (genau wie
obiges Gruppierungsklammerpaar). Der Unterschied besteht lediglich
darin, was als normales Zeichen angesehen wird und was eine eingebaute
Sonderbedeutung im Sinne des regulären Ausdruckes hat.
Und bei BRE muss aus einem '+', was dort eben zunächstmal ein normales
Zeichen ist, durch Voranstellen von '\' erst ein RE + Quantor
gemacht werden.
AFAIK geht dabei die mMn wesentlich praxisgerechtere Interpretation im
Sinne der ERE (wo das genau umgekehrt ist) ursprünglich auf Perl
zurück.
Eine Vereinheitlichung dieses äußerst unschönen Wirrwarrs wäre
dringend nötig und das sollte dann auf jeden Fall PCRE (Perl
Compatible Regular Expressions) werden - natürlich dann auch bei sed.
Bernd
--
No time toulouse
> Das '+' gibt es auch in den Basic Regular Expressions
Nein. \|, \+, \? sind GNU-Erweiterungen.
--
Christian "naddy" Weisgerber na...@mips.inka.de
> On 2009-10-29, Juergen Ilse wrote:
>
>>>> "[0-9][0-9]*" : Eine oder mehr Ziffern (eine Zahl).
>>> "[0-9]+" : Eine oder mehr Ziffern (eine Zahl).
>
>> Das gibt es nur bei "extended regular expressions".
>
> Das '+' gibt es auch in den Basic Regular Expressions
Nein, gibt es nicht!
http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03
"+" : „a BRE ordinary character“
"\+" : „interpretation undefined“
"[\+]" : „RE bracket expression“ ('\' oder '+')
BRE special characters : . [ \ * ^ $
> Und bei BRE muss aus einem '+', was dort eben zunächstmal
> ein normales Zeichen ist, durch Voranstellen von '\' erst ein
> RE + Quantor gemacht werden.
GNU sed »extension«. Laut IEEE Std. 1003.1 ist die Deutung
(„interpretation“) von "\+" unbestimmt („undefined“).
> AFAIK geht dabei die mMn wesentlich praxisgerechtere
> Interpretation im Sinne der ERE (wo das genau umgekehrt
> ist) ursprünglich auf Perl zurück.
ERE basiert auf egrep(1); Perl RE basiert auf ERE.
--
printf -v email $(echo \ 155 141 162 143 145 154 142 162 165 151 \
156 163 155 141 100 171 141 150 157 157 056 143 157 155|tr \ \\\\)
# Live every life as if it were your last! #
[XPost & Fup to de.comp.os.unix.shell]
Interessanterweise funktioniert das so auch mit dem NetBSD sed:
----------------------------------------------------------------------
$ echo "STRINGG_DP_3" | nbsed 's/P_\([0-9]\+\)/\1P/g'
STRINGG_D3P
----------------------------------------------------------------------
Obwohl in der manpage von nbsed steht:
|
| The sed regular expressions are basic regular expressions (BRE's,
| see re_format(7) for more information). In addition, sed has the
| following two additions to BRE's:
|
| 1. In a context address, any character other than a backslash
| (``\'') or newline character may be used to delimit the regular
| expression by prefixing the first use of that delimiter with a
| backslash. Also, putting a backslash character before the
| delimiting character causes the character to be treated
| literally. For example, in the context address \xabc\xdefx,
| the RE delimiter is an ``x'' and the second ``x'' stands for
| itself, so that the regular expression is ``abcxdef''.
|
| 2. The escape sequence \n matches a newline character embedded in
| the pattern space. You can't, however, use a literal newline
| character in an address or in the substitute command.
Wie Marcel schrieb hat '+' laut POSIX in einem BRE eigentlich keine
Sonderfunktion. Das steht bei NetBSD ebenfalls in der manpage re_format:
|
| Obsolete (``basic'') regular expressions differ in several respects.
| `|', `+', and `?' are ordinary characters and there is no
| equivalent for their functionality.
Es duerfte doch also eigentlich nicht gehen. '\+' koennte bei nbsed
wegen Punkt 1 maximal zum Delimiter mutieren aber sollte IMHO nie "ein
oder mehrmals" bedeuten ... was verstehe ich hier falsch?
BTW: NetBSD versteht "sed -r" nicht und will stattdessen "sed -E" sehen
(was wiederum mit dem GNU sed nicht geht).
Micha
> Interessanterweise funktioniert das so auch mit dem NetBSD sed:
> ----------------------------------------------------------------------
> $ echo "STRINGG_DP_3" | nbsed 's/P_\([0-9]\+\)/\1P/g'
> STRINGG_D3P
> ----------------------------------------------------------------------
Bei mir nicht. NetBSD 5, sed ist /usr/bin/sed.
J�rg
>>>>> "[0-9][0-9]*" : Eine oder mehr Ziffern (eine Zahl).
>>>> "[0-9]+" : Eine oder mehr Ziffern (eine Zahl).
>>> Das gibt es nur bei "extended regular expressions".
>> Das '+' gibt es auch in den Basic Regular Expressions
> Nein, gibt es nicht!
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03
> "+" : „a BRE ordinary character“
> "\+" : „interpretation undefined“
> "[\+]" : „RE bracket expression“ ('\' oder '+')
> BRE special characters : . [ \ * ^ $
>> Und bei BRE muss aus einem '+', was dort eben zunächstmal
>> ein normales Zeichen ist, durch Voranstellen von '\' erst ein
>> RE + Quantor gemacht werden.
> GNU sed »extension«. Laut IEEE Std. 1003.1 ist die Deutung
> („interpretation“) von "\+" unbestimmt („undefined“).
>> AFAIK geht dabei die mMn wesentlich praxisgerechtere
>> Interpretation im Sinne der ERE (wo das genau umgekehrt
>> ist) ursprünglich auf Perl zurück.
> ERE basiert auf egrep(1); Perl RE basiert auf ERE.
Danke für die zusätzlichen Informationen - wieder was dazu gelernt!
> > Interessanterweise funktioniert das so auch mit dem NetBSD sed:
> > ----------------------------------------------------------------------
> > $ echo "STRINGG_DP_3" | nbsed 's/P_\([0-9]\+\)/\1P/g'
> > STRINGG_D3P
>
> Bei mir nicht. NetBSD 5, sed ist /usr/bin/sed.
Der implementiert die REs nicht selbst, sondern reicht sie an
regcomp(3) usw. in der lokalen libc durch.
> Interessanterweise funktioniert das so auch mit dem NetBSD sed:
> ----------------------------------------------------------------------
> $ echo "STRINGG_DP_3" | nbsed 's/P_\([0-9]\+\)/\1P/g'
> STRINGG_D3P
> ----------------------------------------------------------------------
Interessanterweise funktioniert das mit meinem NetBSD sed
(/usr/bin/sed) nicht. ;-)
ftp://ftp.nl.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/regex/regcomp.c
Wie man in p_simp_re() sehen kann, werden nur "\{", "\}", "\(",
"\)" und "\1"..."\9" als Sonderfälle gehandelt. Der Ausdruck "\+"
wird als ordinary(,'+') verarbeitet.
Anscheinend benutzt Dein nbsed nicht die NetBSD libc.
> BTW: NetBSD versteht "sed -r" nicht und will stattdessen "sed -E"
> sehen (was wiederum mit dem GNU sed nicht geht).
ftp://ftp.nl.netbsd.org/pub/NetBSD/NetBSD-current/src/usr.bin/sed/sed.1
„-r Identical to -E, present for compatibility with GNU sed.“
Update vielleicht?
In der Tat, ich habe den nbsed aus pkgsrc auf einem Linux benutzt. Eine
NetBSD libc gibts da natuerlich keine. Ich hatte es nicht so genau
angeschaut und dachte daher die libc spielt keine Rolle.
> > BTW: NetBSD versteht "sed -r" nicht und will stattdessen "sed -E"
> > sehen (was wiederum mit dem GNU sed nicht geht).
>
> ftp://ftp.nl.netbsd.org/pub/NetBSD/NetBSD-current/src/usr.bin/sed/sed.1
> �??-r Identical to -E, present for compatibility with GNU sed.�??
>
> Update vielleicht?
Ich war eigentlich der Meinung, dass der letzte CVS-sync nicht laenger
als eine Woche her ist, aber das schaue ich am Montag nochmal an. Oder
die Version in pkgsrc ist nicht die gleiche wie im Basissystem.
Meine Frage hat sich damit jedenfalls erledigt.
Micha
--
Alte Maenner sind Kinder mit Rueckenschmerzen.
Raimund Nisius in dse
# cd /usr/pkgsrc/textproc/nbsed
# cvs update -dP .
# bmake replace
# pkg_info | grep nbsed
nbsed-20040821nb1 NetBSD-current's sed(1)
Macht einen ziemlich abgehangenen Eindruck. Diese Version versteht
jedenfalls noch kein "-r".
Micha