bug#34316: sed misbehavior on BRE's

[Lange, Markus]

Hi,

as said i've tested using sed 4.7 on an archlinux.

# sed --version
sed (GNU sed) 4.7
...

Using LANG=C (LC_* unset) works as expected:
# LANG=C sed -n 's/^.*004K...\([0-
9xX]\{13\}\).*006V...\(.\{1,32\}\).*\(.020F.*\)021A.*$/\2 \1\3/p'
Fehlerpica.dat
138742c156c1445f8bdc3a7845548c00 9783507435339020F a19.04.03
18290030a02544e6a451538b0e44f9e2 9783507435377020F a19.04.03
4c7ff6d790b34470852434f5ee41200b 9783034312189020F a12.12.11

Using LANG=en_us.utf8 don't get results.

Best regards,
Markus Lange


On Tue, 2019-02-05 at 16:12 -0700, Assaf Gordon wrote:
> tags 34316 moreinfo
> stop
> 
> Hello,
> 
> On 2019-02-04 6:42 a.m., Lange, Markus wrote:
> > I'm currently migrating processes from an old SuSE 9 Linux to an
> > new
> > CentOS 7 Linux and observed some unexpected behavior changes on
> > sed.
> 
> [...]
> > old:~ # sed --version
> > GNU sed version 4.0.6
> 
> [...]
> > new:~ # sed --version
> > sed (GNU sed) 4.2.2
> 
> Please note that sed 4.2.2 is also very old (7 years old).
> The latest sed is version 4.7, released in December 2018.
> 
> There's limited amount of support we can help with sed-4.2.2 .
> 
> 
> Before digging further, I notice that the file you're dealing with
> has non-ascii characters in it, evident by some of the example text
> you pasted (and also in the attached file):
> 
> > 9xX]\{13\}\).*006V...\(.\{1,32\}\).*\(.020F.*\)021A.*/\2 \1\3/p'
> > Fehlerpica.dat
> > 138742c156c1445f8bdc3a7845548c00 9783507435339020F
> > a19.04.03�208@
> > a30-01-19bc
> > 18290030a02544e6a451538b0e44f9e2 9783507435377020F
> > a19.04.03�208@
> > a30-01-19bc
> > 4c7ff6d790b34470852434f5ee41200b 9783034312189020F
> > a12.12.11�208@
> > a30-01-19bc
> 
> And such characters can cause unexpected results, depending on the
> active locale.
> 
> Can you please re-run the tests on the new machine with the same
> locale as the old machine, and again with LC_ALL=C (forcing C/POSIX
> locale), to ensure that locale and invalid characters are not the
> problem ?
> 
> Also, even if you're 'stuck' with sed-4.2.2, can you try with
> sed-4.7 (perhaps compiled from source code), to see if this is an
> existing problem, or perhaps it was resolved in the meantime?
> 
> 
> regards,
>   - assaf
> 
>