From 6106b56191a0ee3807d3d662f6f0b9ffb69f003e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 19 Apr 2022 13:24:42 -0700 Subject: [PATCH] =?utf8?q?doc:=20prefer=20=C3=B6=20to=20$'\u7530'?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit * doc/coreutils.texi (Character arrays): Avoid using shell notation like $'\u7530' since this isn’t in POSIX yet. Instead, use ö and Ł which should work in all texinfo output formats. --- doc/coreutils.texi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/coreutils.texi b/doc/coreutils.texi index e7b53af536..35fde52892 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -6972,10 +6972,10 @@ The interpretation of @var{string1} and @var{string2} depends on locale. GNU @command{tr} fully supports only safe single-byte locales, where each possible input byte represents a single character. Unfortunately, this means GNU @command{tr} will not handle commands -like @samp{tr $'\u7530' $'\u68EE'} the way you might expect, +like @samp{tr @"o @L{}} the way you might expect, since (assuming a UTF-8 encoding) this is equivalent to -@samp{tr '\347\224\260' '\346\243\256'} and GNU @command{tr} will -simply transliterate all @samp{\347} bytes to @samp{\346} bytes, etc. +@samp{tr '\303\266' '\305\201'} and GNU @command{tr} will +simply transliterate all @samp{\303} bytes to @samp{\305} bytes, etc. POSIX does not clearly specify the behavior of @command{tr} in locales where characters are represented by byte sequences instead of by individual bytes, or where data might contain invalid bytes that are -- 2.47.2