grep branch, master, updated. v2.20-81-g2ac3551

[Jim Meyering]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "grep".

The branch, master has been updated
       via  2ac355101d867f3231fd62ee131c0c98bb2eafa1 (commit)
       via  393d19a58d48daad81536b54d92847f29f362740 (commit)
      from  79c1479c8dbad03214696b16a78a61b03d25b3a1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=2ac355101d867f3231fd62ee131c0c98bb2eafa1


commit 2ac355101d867f3231fd62ee131c0c98bb2eafa1
Author: Jim Meyering <address@hidden>
Date:   Sat Nov 8 18:59:24 2014 -0800

    tests: avoid a multibyte tr portability problem
    
    * tests/init.cfg (tr): New wrapper function.
    See comments for details.  Reported by Norihiro Tanaka
    in http://debbugs.gnu.org/18991

diff --git a/tests/init.cfg b/tests/init.cfg
index 75a9494..e7a2389 100644
--- a/tests/init.cfg
+++ b/tests/init.cfg
@@ -162,3 +162,12 @@ hex_printf_()
   printf $(printf '\\%o' \
     $(printf %s "$1"|sed 's,\\x\([0-9a-fA-F][0-9a-fA-F]\), 0x\1,g'))
 }
+
+# Wrap tr so that it always runs in the C locale.
+# Otherwise, in a multibyte locale, GNU tr (which is not multibyte-aware
+# as of 2014-11-08), would work differently than others.  For example,
+# this command, which was written with unibyte GNU tr in mind,
+#   LC_ALL=ja_JP.eucJP tr AB '\244\263'
+# would act like this with the multibyte tr from HP-UX and Solaris:
+#   LC_ALL=ja_JP.eucJP tr A  '\244\263'
+tr() { LC_ALL=C env -- tr "$@"; }

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=393d19a58d48daad81536b54d92847f29f362740


commit 2ac355101d867f3231fd62ee131c0c98bb2eafa1
Author: Jim Meyering <address@hidden>
Date:   Sat Nov 8 18:59:24 2014 -0800

    tests: avoid a multibyte tr portability problem
    
    * tests/init.cfg (tr): New wrapper function.
    See comments for details.  Reported by Norihiro Tanaka
    in http://debbugs.gnu.org/18991

diff --git a/tests/init.cfg b/tests/init.cfg
index 75a9494..e7a2389 100644
--- a/tests/init.cfg
+++ b/tests/init.cfg
@@ -162,3 +162,12 @@ hex_printf_()
   printf $(printf '\\%o' \
     $(printf %s "$1"|sed 's,\\x\([0-9a-fA-F][0-9a-fA-F]\), 0x\1,g'))
 }
+
+# Wrap tr so that it always runs in the C locale.
+# Otherwise, in a multibyte locale, GNU tr (which is not multibyte-aware
+# as of 2014-11-08), would work differently than others.  For example,
+# this command, which was written with unibyte GNU tr in mind,
+#   LC_ALL=ja_JP.eucJP tr AB '\244\263'
+# would act like this with the multibyte tr from HP-UX and Solaris:
+#   LC_ALL=ja_JP.eucJP tr A  '\244\263'
+tr() { LC_ALL=C env -- tr "$@"; }

-----------------------------------------------------------------------

Summary of changes:
 tests/init.cfg       |    9 +++++++++
 tests/word-multibyte |    2 --
 2 files changed, 9 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
grep