[geos-devel] GEOS 3.7.0rc1 release

[Greg Troxel]

Sebastiaan Couwenberg <sebastic at 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

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 (.*)?

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20180821/b2fec655/attachment.sig>