[geos-devel] GEOS 3.7.0rc1 release

[Sebastiaan Couwenberg]

On 8/21/18 3:26 PM, Greg Troxel wrote:
> 
> 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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20180821/e9a01e21/attachment-0001.sig>