Re: parenthesised regular expressions and non-greedy operator ? - non standard bash behaviour

2017-12-04 Thread H.-Dirk Schmitt
>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/xx.dyn?csRdu=https://www.medimops.de/?anid=M9
> > 9&cl=details&wdm=M99&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
> 



Re: parenthesised regular expressions and non-greedy operator ? - non standard bash behaviour

2017-12-04 Thread H.-Dirk Schmitt
On Mo, 2017-12-04 at 16:49 -0500, Chet Ramey wrote:
> The thing is, bash doesn't "implement" its regular expressions, per
> se.
> Bash uses the Posix standard library functions (regcomp/regexec) if
> they
> are available in the C library when it's configured and built.  I'm
> not
> wild about adding a dependency on pcre, or a configure test for it,
> just
> to have two varieties of regular expressions available.
> 
> Chet

O.k.  – so close this as „not a bug“.


-- 




  
  

  Signature H.-Dirk Schmitt



  

  

  H.-Dirk Schmitt
  

  Dipl.Math.

  eMail:dirk.schm...@computer42.org
  

  mobile:+49 177 616 8564
  

  phone: +49 2642 99 41 14
  

  fax: +49 2642 99 41 15
  

  Schillerstr. 42, D-53489 Sinzig

  pgp: http://www.computer42.org/~dirk/OpenPGP-fingerprint.html




Missing documentation of the integer range (declare -i)

2017-12-06 Thread H.-Dirk Schmitt
Checked against:  GNU bash, Version 4.4.12(1)-release (x86_64-pc-linux-
gnu) 

I carefully read the man page and find no definition of the defined
range of integer variables in bash.
see also:  `man bash |& grep -i integer`

Best Regards,

H.-Dirk Schmitt