[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: parenthesised regular expressions and non-greedy operator ? - non st
Re: parenthesised regular expressions and non-greedy operator ? - non standard bash behaviour
Mon, 04 Dec 2017 19:42:05 +0100
>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
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
So please feel free to change the „bug report“ to a „feature request“
On So, 2017-12-03 at 15:23 -0500, Chet Ramey wrote:
> On 12/1/17 12:40 PM, address@hidden 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
> There's no concept of a `non-greedy' operator
> in the Posix ERE definition.