Forwarding to the bug tracking system: ---------- Forwarded message ---------- From: Jim Meyering <j...@meyering.net> Date: Sun, Nov 9, 2014 at 10:23 AM Subject: Re: bug#18987: the bourne shell printf-vs-\xHH portability trap To: Paul Eggert <egg...@cs.ucla.edu>
On Sun, Nov 9, 2014 at 9:36 AM, Jim Meyering <j...@meyering.net> wrote:
> On Sat, Nov 8, 2014 at 7:52 PM, Paul Eggert <egg...@cs.ucla.edu> 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
