Front page | perl.perl5.porters |
Postings from March 2014
Re: lib/locale.t warnings
Thread Previous
|
Thread Next
From:
Karl Williamson
Date:
March 5, 2014 20:11
Subject:
Re: lib/locale.t warnings
Message ID:
531784C2.1050403@khwilliamson.com
On 02/24/2014 04:31 AM, Dave Mitchell wrote:
> On Sun, Feb 23, 2014 at 06:00:26PM +0000, Dave Mitchell wrote:
>> On Sun, Feb 23, 2014 at 10:47:09AM -0700, Karl Williamson wrote:
>>> On 02/23/2014 07:50 AM, Dave Mitchell wrote:
>>>> I haven't been following the recent locale.t threads very closely, since
>>>> they seem to relate to test failures on platforms I don't use.
>>>> However, recently, I've started seeing *warnings* generated by locale.t.
>>>> For example on today's blead v5.19.9-28-gdca36a0, on Linux I see:
>>>>
>>>> $ ./perl harness run/locale.t
>>>> run/locale.t .. 8/19 sh: warning: setlocale: LC_ALL: cannot change locale (invalid): No such file or directory
>>>> sh: warning: setlocale: LC_ALL: cannot change locale (invalid): No such file or directory
>>>> run/locale.t .. ok
>>>> All tests successful.
>>>> Files=1, Tests=19, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.68 cusr 0.09 csys = 0.81 CPU)
>>>> Result: PASS
>>>>
>>>> It appears to be this part of the test file:
>>>>
>>>> local $ENV{LC_ALL} = "invalid";
>>>> local $ENV{LC_NUMERIC} = "invalid";
>>>> local $ENV{LANG} = $_;
>>>>
>>>> # Can't turn off the warnings, so send them to /dev/null
>>>> fresh_perl_is(<<'EOF', "$difference", { stderr => "devnull" },
>>>> ....
>>>>
>>>> And it appears to be that fresh_perl_is() is spawning a shell which then
>>>> spawns perl, which runs the test code. But the invalid LC_ALL is seen by
>>>> the intervening shell, which is generating the warnings.
>>>>
>>>> I'm not sure what the best workaround is.
>>>>
>>>
>>> I don't get that on my Linux. What sh are you using?
>>
>> $ rpm -qf /bin/sh
>> bash-4.2.45-1.fc18.x86_64
>>
>> This is Fedora 18.
>
> and here it is demoed:
>
> $ LC_ALL=invalid /bin/sh -c 'echo yes'
> /bin/sh: warning: setlocale: LC_ALL: cannot change locale (invalid): No such file or directory
> yes
> $
>
>
>
Note that when this happens, the test is not actually testing what it
purports to be, as the environment variable doesn't get changed (at
least on dromedary and my Ubuntu); hence the test might as well be skipped.
Another possibility is to do a Configure probe, so we know to skip these
tests. I don't know about the feasibility of this, nor the gotchas,
like what if it happens on one shell but not another on the system.
Thread Previous
|
Thread Next