Question about language setting

Discussion in 'Perl Misc' started by Dave Saville, Dec 23, 2013.

  1. Dave Saville

    Dave Saville Guest

    I have a perl script that checks a program's "data base" for

    A German user said it would not run and threw a "Feature bundle 5.0.0"
    not supported from This was because I call Carp.

    He now says

    the perl problem seems to be solved: it's not a problem with
    installation or version. The problem is the setting for "LANG": It has
    to be LANG=en_US.UTF-8 and not LANG=de_DE_EURO which is the standard
    for german!

    Surely (base) perl modules aren't dependent on language?
    Dave Saville, Dec 23, 2013
    1. Advertisements

  2. According to a completely random web search result,

    the issue is possibly that the 5.0 becomes 5,0 when formatted
    according to German conventions. The thread and related bug & bugfix has
    some more information on this (AFAIK, 'feature bundle 5.0.0' means
    Rainer Weikusat, Dec 23, 2013
    1. Advertisements

  3. Dave Saville

    Dave Saville Guest

    Well that seems to suggest that it is not perl but something else

    root source found, the bug is not in perl, its in Illumos locales,

    Whatever that is. Surely perl must be used in non English speaking
    countries? :)
    Dave Saville, Dec 23, 2013
  4. As I already wrote: The thread and the associated OpenSlowalrus bug &
    bug fix provide some more background information on this. In particular,
    the suggested workaround (set LC_NUMERIC to a 'decimal point' locale)
    should be sufficient to determine if this is really the same
    problem. Depending on how you feel about that, you might also just tell
    your user that "Locale support on your system is obviously broken, get
    of my lawn, sucker!" -- the open source way of dealing with
    'uninteresting' user problems ...
    Rainer Weikusat, Dec 23, 2013
  5. It would be useful to know where this error occurs. Just "a perl script"
    is a bit vague.

    I get this error if I write something like

    use feature ':5.0.0';

    but that is independent of the locale setting. was introduced
    in 5.10 and there aren't any feature bundles less than :5.10.

    Also, details about the system in question (OS/distribution, perl
    version) would also be useful.
    They shouldn't be. It might be a bug in perl, in the module or in a
    system library. Or it might be a bug in your script. It is impossible to
    tell with the information you have given.

    Peter J. Holzer, Dec 23, 2013
  6. Considering the statement from 'the user', this must be something which
    causes the behaviour of some perl code to change because it is using a
    German locale. Considering what is in a locale definition, this makes
    LC_NUMERIC the most likely candidate, especially considering that this
    is the only locale-information used as part of version checking (by
    Perl_upg_version in util.c).
    Rainer Weikusat, Dec 23, 2013
  7. Yes, I know. But I couldn't reproduce it. And that's not very
    surprising: Many people use perl with a German locale, so it can't be
    something generic like "perl doesn't work with a German locale" or "use
    feature doesn't work with a German locale". It has to be something more
    specific, like a bug in the locale implementation of the user's system
    (but Dave hasn't told us what system it is) or the way a certain feature
    is used (but Dave hasn't told us anything about his script). But it is
    impossible to find out what it is unless Dave volunteers more

    Peter J. Holzer, Dec 23, 2013
  8. Dave Saville

    Dave Saville Guest

    A little difficult to post extra info from the user as I only have a
    jpeg of the errors rather than something I can cut and paste :-(

    The script starts:

    use strict;
    use warnings;
    use Carp:
    use Encode;

    Compilation failed in require at .... line 3 - ie the "use Carp" line.

    System is OS/2 his perl is 5.10.0. (Yes I know :) )

    If you follow the links from the posted forum you end up with a C test
    program. I have built that on my system but as I am in the UK my
    system is defaulting to using a 'point' anyway. I have yet to persuade
    it to start up in a different locale. I know how to get a program to
    use a different language but that does not seem to help. I have posted
    this problem to an OS/2 tech group in the hope they may throw some
    light on the problem - assuming it is a similar one in that
    setlocale() is not working correctly as per the forum post.
    Dave Saville, Dec 24, 2013
  9. According to some more searching around on the web, the OS/2 command to
    set a locale is (example)

    set lang=de_DE

    Results as to whether or not setlocale works on OS/2 are somewhat
    unclear. Assuming your system starts with 'English' language settings,
    you could use a modified test program,

    #include <locale.h>
    #include <stdio.h>

    int main(void) {
    setlocale(LC_NUMERIC, "de_DE");
    setlocale(LC_NUMERIC, "C");

    return 0;

    this should print (possibly with variations in the number of trailing


    If it doesn't, in particular, if there's a dot instead of a comma in the
    second line, setlocale doesn't work as it is supposed to and if you
    can't switch from English to German in this way, chances are very high
    that switching from German to English also won't work.
    Rainer Weikusat, Dec 27, 2013
  10. Dave Saville

    Dave Saville Guest

    It would appear we have the same or very similar problem with
    setlocale() as reported upthread. It is being looked into. FWIW I now
    have the original error in text form:

    Feature bundle "5.0.0" is not supported by Perl 5.10.0 at
    D:/PROGRAMS/PERL/LIB/5.10.0/ line 207
    feature::croak('Feature bundle "5.0.0" is not supported by Perl
    5.10.0') called at D:/PROGRAMS/PERL/LIB/5.10.0/ line 201
    feature::unknown_feature_bundle(5.0.0) called at
    D:/PROGRAMS/PERL/LIB/5.10.0/ line 152
    feature::import('feature', ':5.0.0') called at
    D:/PROGRAMS/PERL/LIB/5.10.0/ line 3
    Exporter::BEGIN() called at D:/PROGRAMS/PERL/LIB/5.10.0/
    line 0
    eval {...} called at D:/PROGRAMS/PERL/LIB/5.10.0/ line 0
    require called at D:/PROGRAMS/PERL/LIB/5.10.0/
    line 14
    require called at c:\progr\pmmail3\bin\
    line 13
    main::BEGIN() called at D:/PROGRAMS/PERL/LIB/5.10.0/ line 0
    eval {...} called at D:/PROGRAMS/PERL/LIB/5.10.0/ line 0
    BEGIN failed--compilation aborted.
    Compilation failed in require at D:/PROGRAMS/PERL/LIB/5.10.0/
    line 14.
    Compilation failed in require at
    c:\progr\pmmail3\bin\ line 13.
    BEGIN failed--compilation aborted at
    c:\progr\pmmail3\bin\ line 13.

    The only difference between this and the stripped down code I posted
    earlier is that this script starts with ten comment lines so 13 above
    is my test's 3. ie the use Carp; line.
    Dave Saville, Dec 27, 2013
  11. Am 24.12.2013 11:39, schrieb Dave Saville:
    i have not read the whole tread,
    but how about using 'use Carp;' instead of 'use Carp:'?

    Martin Gieretz, Dec 27, 2013
  12. Dave Saville

    Dave Saville Guest

    On Fri, 27 Dec 2013 14:59:11 UTC, Martin Gieretz

    Which would throw a syntax error not what we are seeing - My bad I
    just typed the three "use" lines into the mail, not copy/paste.
    Dave Saville, Dec 27, 2013
  13. Dave Saville

    Dave Saville Guest


    use strict;
    use warnings;
    use Carp;

    printf("%f\n", 2.5);

    Using perl 5.16.0

    Invalid version format (non-numeric data) at
    u:/perl5/lib/5.16.0/ line 3.

    BEGIN failed--compilation aborted at u:/perl5/lib/5.16.0/ line
    Compilation failed in require at line 3.
    BEGIN failed--compilation aborted at line 3.

    Carp line 3 says { use 5.006; }

    Using perl 5.8.2

    perl: warning: Setting locale failed.
    perl: warning: Please check that your locale settings:
    LC_ALL = (unset),
    LANG = "de_DE_EURO"
    are supported and installed on your system.
    perl: warning: Falling back to the standard locale ("C").

    Which is a darn site more useful IMHO.

    As the OS/2 setlocale() seems to suffer the same problem as the other
    OS above is there a perlish way around this one?

    The problem I have is that I am comparing strings from two sources.
    One where the string is in the local code page and the other in utf8.
    I solved this by using Encode and friends but that introduces the
    requirement for Carp and the above error :-(
    Dave Saville, Dec 29, 2013
  14. Yup. I think somebody (Rainer?) had already pointed out this line as the
    likely culprit.
    You could try

    BEGIN { $ENV{LANG} = 'C' }

    Yes, Encode contains the necessary functions (But depending on the
    source it may be more convenient to use an I/O filter or soemthing
    similar instead of calling Encode::decode() explicitely).

    I'm not sure why using Encode requires the use of Carp, but in any case

    { use 5.006; }

    is valid Perl and must compile successfully, regardless of any locale

    Is OS/2 still officially supported by Perl? It isn't on anymore.

    A viable workaround might be to compile perl on OS/2 without locale
    support (since it doesn't seem to work correctly anyway). But that would
    also mean that your users need to use this locale-less perl binary,
    which may break some other scripts they use.

    Peter J. Holzer, Dec 29, 2013
  15. Dave Saville

    Dave Saville Guest

    Hi Ben
    A clever man (ie not me) has found the problem.

    perl is built with locale.h
    libc is built with unidef.h

    The definitions of LC_NUMERIC and LC_MONETARY are reversed between
    the two. Correcting locale.h to match unidef.h results in the posted C
    testcase to work as expected. Our perl porter is rebuilding a version
    with this change.
    Would you mind doing this please? I am not sure I can write a ticket
    that others could act on.
    Dave Saville, Dec 30, 2013
  16. Dave Saville

    Dave Saville Guest

    Now the first problem is solved, see elseehere in this tree, on to the
    next :)

    I have two input files the creation of which I have no control over.
    One has been written, from C, using whatever codepage the user has.
    The other file is encoded utf8.

    Both files contain a file name. One of the consistancy checks is to
    see if they match. I can read in the second file with open my $FILE2,
    '<:encoding(utf8)", .......

    So how to open the first?

    open my $FILE1, '<', .....
    open my $FILE1, <:raw', ....
    open my $FILE1, '<', .........
    binmode $FILE;

    All seem to do exactly the same thing - except for \r\n processing.


    open my $FILE1, '<:encoding(whatever)', ......

    When perl converts to internal utf8 how does it decide to map code
    points > 127 when it is not told the cp? It does not default to
    current as I run with 850 and opening '<:encoding(cp850)' gives a
    different result for points > 127 than does open '<'. It's complicated
    by the fact that the field separator on the first file is hex DE that
    will get mangled in the former case. But my $sep = decode("cp$cp",
    "\xDE"); where $cp is the codepage seems to get around that one.

    What I need to be able to do is

    if ( $file1name eq $file2name ) where the names have accented

    Dave Saville, Dec 30, 2013
  17. Dave Saville

    Dave Saville Guest

    Many thanks Ben. As I said I didn't "design" the 0xDE bit :) This
    code is checking files of a program that only runs on OS/2 so
    portability is not a question.
    Dave Saville, Dec 30, 2013
  18. There is the Encode::Locale module, which allows you to do something
    open(my $fh, '<:encoding(locale)', $filename);

    I don't think it works on OS/2 (A colleague recently told me it doesn't
    even work on Windows), but I think it would be better to extend an
    existing module to work on more platforms than to add another
    platform-specific module.

    Peter J. Holzer, Dec 30, 2013
  19. * Peter J. Holzer wrote in comp.lang.perl.misc: has some
    thoughts about Windows support in that area.
    Bjoern Hoehrmann, Dec 30, 2013
  20. setlocale() returns a char* that's either a pointer to a string (if it
    succeeded), or a null pointer (if it failed). It's probably worth
    adding code to check for this rather than just depending on the output
    of printf to change. (On my system, the first setlocale() call fails
    because I don't have any German locales installed.)
    Keith Thompson, Dec 31, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.