On 8/21/18 3:26 PM, Greg Troxel wrote: > > Sebastiaan Couwenberg <sebas...@xs4all.nl> writes: > >> On 8/21/18 1:25 AM, Greg Troxel wrote: >>> >>> is malformed. It's the .* production that the ? applies to (present or >>> not). >>> >>> VERSION_RELEASE=`echo "$VERSION" | sed -E >>> 's/^([0-9]+\.[0-9]+\.[0-9]+)(.*)?$/\1/'` >>> >>> GNU sed may be allowing this as an extension, because "*?" doesn't make >>> sense, since * is repetition. >> >> Note the -E option for extended regular expressions which came from GNU >> sed but is now included in POSIX. >> >> The ? should make the .* expression non-greedy. > > Sorry, I am not following. I dug into this harder than probably makes > sense because I wanted to make sure there wasn't a bug in NetBSD's sed, > in which case I would file a bug report so it is fixed. > > I don't see -E in POSIX's sed spec: > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
It's documented in the sed manpage: " POSIX.2 BREs should be supported, but they aren't completely because of performance problems. The \n sequence in a regular expression matches the newline character, and similarly for \a, \t, and other sequences. The -E option switches to using extended regular expressions instead; the -E option has been supported for years by GNU sed, and is now included in POSIX. " https://manpages.debian.org/stretch/sed/sed.1.en.html#REGULAR_EXPRESSIONS > However, NetBSD's sed (and I suspect basically all others) does document > -E for extended regular expressions. > > But, in the posix spec for extended regular expressions: > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html > > I don't see that .*? is legal, opposed to (.*)? That's probably because we're thinking in Perl compatible regular expressions, the dominant regex implementation thanks to PCRE, but POSIX extended regular expressions don't support that feature. > Specifically, in 9.4.6.4, it says > > The behavior of multiple adjacent duplication symbols ( '+', '*', '?', > and intervals) produces undefined results. > > and it looks like this ? modifier is a perl regex thing: > > > https://stackoverflow.com/questions/1103149/non-greedy-reluctant-regex-matching-in-sed Exactly, see above. > But I don't understand why this is hard in this particular, case, since > we're trying to take things like > > 1.2.3 > 3.4.5rc3 > > and produce > > 1.2.3 > 3.4.5 > > and I would think the point is to have the .* eat up everything after > the third number. More specifically thinks like: 3.7.0alpha 3.7.0beta1dev And (unlikely) cases like: 3.42.123beta1dev Once again see the discussion in the related issue: https://trac.osgeo.org/geos/ticket/887 One way or another the suffix needs to be stripped from the version number, because it shouldn't become part of the library filename. Initially the suffix was matched, but later changed to match the version to handle the dev case in particular, and any other possible suffix we hadn't thought of. Kind Regards, Bas
signature.asc
Description: OpenPGP digital signature
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel