bug#18987: Fwd: bug#18987: the bourne shell printf-vs-\xHH portability trap

[Jim Meyering]

Forwarding to the bug tracking system:

---------- Forwarded message ----------
From: Jim Meyering <address@hidden>
Date: Sun, Nov 9, 2014 at 10:23 AM
Subject: Re: bug#18987: the bourne shell printf-vs-\xHH portability trap
To: Paul Eggert <address@hidden>


On Sun, Nov 9, 2014 at 9:36 AM, Jim Meyering <address@hidden> wrote:
> On Sat, Nov 8, 2014 at 7:52 PM, Paul Eggert <address@hidden> wrote:
>> I have some qualms about that patch.  It assumes the C locale, and it's a
>> bit safer to spell it out as in '0-9abcdefABCDEF'.  Also, the temporary
>> streams (i.e., the output of 'COMMAND inside '$(COMMAND)') are not text, and
>> arguably this does not conform to POSIX (POSIX is murky here) and anyway I
>> suspect some picky shells will complain.  Third and most important, it'd be
>> nicer if hex_printf_ worked like 'printf', except with support for
>> hexadecimal escapes.
>>
>> How about something like the following instead?  It's brute-force, but it
>> should be portable.
>>
>>   hex_printf_()
>>   {
>>     hex_printf_format=$(printf '%s\n' "$1" | sed '
>>       s/^/_/
>>       s/$/_/
>>       s/\([^\\]\(\\\\\)*\\x\)\([0-9aAbBcCdDeEfF][^0-9aAbBcCdDeEfF]\)/\10\3/g
>
> I do like the idea, but now prefer to defer that until after the release.
> Instead, I'll address the portability issues you mentioned, with this:

0001-tests-avoid-hex_printf_-portability-problems.patch
Description: Binary data