>From the 2 replies I unterstand that the implementation in bash is correct due to the „official“ standard.
For myself I have solved the issue in my script - but the regular expression I developed for my problem are without the 'non-greedy' operator more difficult to read and maintain. From that point of view it would be an improvement for bash to implement the non-greedy operator. Also if I look from an „normal developer“ I think it is a common pitfall if many testing resources and regexp implementations support the 'non-greedy' operator. Maybe there is a switch/option to enable the 'non-greedy' operator in a future release. So please feel free to change the „bug report“ to a „feature request“ ;-) Best Regards, H.-Dirk Schmitt On So, 2017-12-03 at 15:23 -0500, Chet Ramey wrote: > On 12/1/17 12:40 PM, d...@computer42.org wrote: > > > Bash Version: 4.4 > > Patch Level: 12 > > Release Status: release > > > > Description: > > I'm sanitising urls from advertisement crap. As described below > > I'm getting a wrong resolution of parenthesised expression defined > > with non-greedy operator '?'. > > > > The test url is: http://toolbox.contentspread.net/container/medim > > ops/track/xxxxxxxxxx.dyn?csRdu=https://www.medimops.de/?anid=M99999 > > 99999&cl=details&wdm=M9999999999&utm_source=CRM&utm_medium=email&ut > > m_campaign=OS > > > > The regular expression is: > > https?:\/\/toolbox.contentspread.net\/(.*?)=(.+?)&.* > > The Bash =~ operator uses Posix extended regexps (EREs) as defined in > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.ht > ml#tag_09_04. > There's no concept of a `non-greedy' operator > in the Posix ERE definition. > > Chet >
