bug#34316: sed misbehavior on BRE's

[Assaf Gordon]

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