From: "Torsten Bögershausen" <tboegi@web.de>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org
Subject: Re: Re*: [PATCH/RFC] Change t0204-gettext-reencode-sanity.sh to pass under Mac OSX
Date: Sun, 11 Mar 2012 16:11:08 +0100 [thread overview]
Message-ID: <4F5CC08C.90703@web.de> (raw)
In-Reply-To: <4F5BD585.5050007@web.de>
On 03/10/2012 11:28 PM, Torsten Bögershausen wrote:
> On 03/09/2012 11:30 PM, Junio C Hamano wrote:
>> Junio C Hamano<gitster@pobox.com> writes:
>>
>>> I would be OK if the patch read like the attached, but I do not
>>> think treating the "show key" and "stuff with ?" case differently
>>> like the original code did makes any sense.
>> Ok, here is a re-roll with proper-ish log message. I've tested this
>> only in one of my VMs with is_IS locale (which happened to be Fedora
>> 15).
>>
>> -- >8 --
>> Subject: [PATCH] t0204: clarify the "observe undefined behaviour" test
>>
>> This test asks for an impossible conversion to the system by
>> preparing an UTF-8 translation with characters that cannot be
>> expressed in ISO-8859-1, and then asking the message shown in
>> ISO-8859-1. Even though the behaviour against such a request is
>> undefined, it may be interesting to see what the system does, and
>> the purpose of this test is to see if there are platforms that
>> exhibit behaviour that we haven't seen.
>>
>> The original recognized two known modes of behaviour:
>>
>> - the key used to query the message catalog ("TEST: Old English
>> Runes"), saying "I cannot do that i18n".
>> - impossible characters replaced with ASCII "?", saying "I punt".
>>
>> but they were treated totally differently. The test simply issued
>> an informational message "Your system punts on this one" for the
>> first error mode, while it diagnosed the latter as "Your system is
>> good; you pass!".
>>
>> It turns out that Mac OS X exhibits a third mode of error behaviour,
>> to spew out the raw value stored in the message catalog. The test
>> diagnosed this behaviour as "broken", but it is merely trying to do
>> its best to respond to an impossible request by saying "I punt" in a
>> way that is slightly different from the second one.
>>
>> Update the offending test to make it clear what is (and is not)
>> being tested, update the code structure so that newly discovered
>> error mode can easily be added to it later, and reword the message
>> that comes from a failing case to clarify that it is not the system
>> that is broken when it fails, but merely that the behaviour is not
>> something we have seen.
>>
>> Signed-off-by: Junio C Hamano<gitster@pobox.com>
>> ---
>> t/t0204-gettext-reencode-sanity.sh | 37
>> ++++++++++++++++++++++--------------
>> 1 file changed, 23 insertions(+), 14 deletions(-)
>>
>> diff --git a/t/t0204-gettext-reencode-sanity.sh
>> b/t/t0204-gettext-reencode-sanity.sh
>> index 189af90..8437e51 100755
>> --- a/t/t0204-gettext-reencode-sanity.sh
>> +++ b/t/t0204-gettext-reencode-sanity.sh
>> @@ -7,6 +7,10 @@ test_description="Gettext reencoding of our *.po/*.mo
>> files works"
>>
>> . ./lib-gettext.sh
>>
>> +# The constants used in a tricky observation for undefined behaviour
>> +RUNES="TILRAUN: ᚻᛖ ᚳᚹᚫᚦ ᚦᚫᛏ ᚻᛖ ᛒᚢᛞᛖ ᚩᚾ ᚦᚫᛗ ᛚᚪᚾᛞᛖ ᚾᚩᚱᚦᚹᛖᚪᚱᛞᚢᛗ ᚹᛁᚦ ᚦᚪ
>> ᚹᛖᛥᚫ"
>> +PUNTS="TILRAUN: ?? ???? ??? ?? ???? ?? ??? ????? ??????????? ??? ??
>> ????"
>> +MSGKEY="TEST: Old English Runes"
>>
>> test_expect_success GETTEXT_LOCALE 'gettext: Emitting UTF-8 from our
>> UTF-8 *.mo files / Icelandic' '
>> printf "TILRAUN: Halló Heimur!">expect&&
>> @@ -15,8 +19,8 @@ test_expect_success GETTEXT_LOCALE 'gettext:
>> Emitting UTF-8 from our UTF-8 *.mo
>> '
>>
>> test_expect_success GETTEXT_LOCALE 'gettext: Emitting UTF-8 from our
>> UTF-8 *.mo files / Runes' '
>> - printf "TILRAUN: ᚻᛖ ᚳᚹᚫᚦ ᚦᚫᛏ ᚻᛖ ᛒᚢᛞᛖ ᚩᚾ ᚦᚫᛗ ᛚᚪᚾᛞᛖ ᚾᚩᚱᚦᚹᛖᚪᚱᛞᚢᛗ ᚹᛁᚦ ᚦᚪ
>> ᚹᛖᛥᚫ">expect&&
>> - LANGUAGE=is LC_ALL="$is_IS_locale" gettext "TEST: Old English
>> Runes">actual&&
>> + printf "%s" "$RUNES">expect&&
>> + LANGUAGE=is LC_ALL="$is_IS_locale" gettext "$MSGKEY">actual&&
>> test_cmp expect actual
>> '
>>
>> @@ -26,18 +30,23 @@ test_expect_success GETTEXT_ISO_LOCALE 'gettext:
>> Emitting ISO-8859-1 from our UT
>> test_cmp expect actual
>> '
>>
>> -test_expect_success GETTEXT_ISO_LOCALE 'gettext: Emitting ISO-8859-1
>> from our UTF-8 *.mo files / Runes' '
>> - LANGUAGE=is LC_ALL="$is_IS_iso_locale" gettext "TEST: Old English
>> Runes">runes&&
>> -
>> - if grep "^TEST: Old English Runes$" runes
>> - then
>> - say "Your system can not handle this complexity and returns the
>> string as-is"
>> - else
>> - # Both Solaris and GNU libintl will return this stream of
>> - # question marks, so it is s probably portable enough
>> - printf "TILRAUN: ?? ???? ??? ?? ???? ?? ??? ????? ??????????? ??? ??
>> ????">runes-expect&&
>> - test_cmp runes-expect runes
>> - fi
>> +test_expect_success GETTEXT_ISO_LOCALE 'gettext: impossible
>> ISO-8859-1 output' '
>> + LANGUAGE=is LC_ALL="$is_IS_iso_locale" gettext "$MSGKEY">runes&&
>> + case "$(cat runes)" in
>> + "$MSGKEY")
>> + say "Your system gives back the key to message catalog"
>> + ;;
>> + "$PUNTS")
>> + say "Your system replaces an impossible character with ?"
>> + ;;
>> + "$RUNES")
>> + say "Your system gives back the raw message for an impossible request"
>> + ;;
>> + *)
>> + say "We never saw the error behaviour your system exhibits"
>> + false
>> + ;;
>> + esac
>> '
>>
>> test_expect_success GETTEXT_LOCALE 'gettext: Fetching a UTF-8 msgid ->
>> UTF-8' '
> Hi Junio and all,
> Thanks, the suggestion looks good to me.
>
> I want be able to test it, but there is one problem:
Here the results of my investigations:
a) git-sh-i18n is used by the test suite, not git-sh-i18n.sh
git-sh-i18n is generated from git-sh-i18n.sh when running make
b) When running
make clean && make USE_GETTEXT_SCHEME=gnu && (cd t && make)
the log of t0204 looks like this:
# lib-gettext: Found 'is_IS.UTF-8' as an is_IS UTF-8 locale
# lib-gettext: Found 'is_IS.ISO8859-1' as an is_IS ISO-8859-1 locale
ok 1 - gettext: Emitting UTF-8 from our UTF-8 *.mo files / Icelandic
ok 2 - gettext: Emitting UTF-8 from our UTF-8 *.mo files / Runes
ok 3 - gettext: Emitting ISO-8859-1 from our UTF-8 *.mo files / Icelandic
ok 4 - gettext: impossible ISO-8859-1 output
ok 5 - gettext: Fetching a UTF-8 msgid -> UTF-8
ok 6 - gettext: Fetching a UTF-8 msgid -> ISO-8859-1
ok 7 - gettext.c: git init UTF-8 -> UTF-8
ok 8 - gettext.c: git init UTF-8 -> ISO-8859-1
# passed all 8 test(s)
1..8
===========
When running
./t0204-gettext-reencode-sanity.sh --verbose
we find the line
"Your system gives back the raw message for an impossible request"
in the log.
Summary: test OK,
May I say
"Thanks for looking into it,
please go ahead with your suggested re-roll" ?
/Torsten
next prev parent reply other threads:[~2012-03-11 15:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-05 19:39 [PATCH/RFC] Change t0204-gettext-reencode-sanity.sh to pass under Mac OSX Torsten Bögershausen
2012-03-05 20:39 ` Junio C Hamano
2012-03-07 21:03 ` Ævar Arnfjörð Bjarmason
2012-03-07 21:34 ` Junio C Hamano
2012-03-07 21:43 ` Ævar Arnfjörð Bjarmason
2012-03-07 21:58 ` Junio C Hamano
2012-03-07 22:04 ` Ævar Arnfjörð Bjarmason
2012-03-07 23:36 ` Junio C Hamano
2012-03-07 23:42 ` Junio C Hamano
2012-03-08 5:54 ` Torsten Bögershausen
2012-03-08 7:23 ` Johannes Sixt
2012-03-08 9:21 ` Torsten Bögershausen
2012-03-08 12:07 ` Torsten Bögershausen
2012-03-09 22:30 ` Re*: " Junio C Hamano
2012-03-10 22:28 ` Torsten Bögershausen
2012-03-11 6:36 ` Junio C Hamano
2012-03-11 15:11 ` Torsten Bögershausen [this message]
2012-03-11 19:22 ` Junio C Hamano
2012-03-11 21:10 ` Torsten Bögershausen
2012-03-11 21:38 ` Junio C Hamano
2012-03-12 20:58 ` Torsten Bögershausen
2012-03-12 21:25 ` Junio C Hamano
2012-03-13 19:19 ` Torsten Bögershausen
2012-03-13 19:32 ` Junio C Hamano
2012-03-12 5:46 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F5CC08C.90703@web.de \
--to=tboegi@web.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).