Professional Web Applications Themes

perlio problem? redhat 9, perl 5.8.0 - PERL Miscellaneous

I'm having some problems running a bit of legacy perl code on a newly installed redhat 9. With the perl 5.8.0 that comes with redhat 9, the match against the string literal works, the match against the same string read from a file fails. The weird thing is that with a 5.8.0 compiled from source with default settings, both matches work, which is what we'd expect. To make the script work you can add a binmode F after the second file open, or you can change the [^\s]+ to [\S]+ or \S+. But the question is, why are either of ...

  1. #1

    Default perlio problem? redhat 9, perl 5.8.0

    I'm having some problems running a bit of legacy perl code on a newly
    installed redhat 9. With the perl 5.8.0 that comes with redhat 9, the
    match against the string literal works, the match against the same
    string read from a file fails.

    The weird thing is that with a 5.8.0 compiled from source with default
    settings, both matches work, which is what we'd expect.

    To make the script work you can add a binmode F after the second file
    open, or you can change the [^\s]+ to [\S]+ or \S+. But the question
    is, why are either of these things necessary? I don't understand the
    fundamental cause of this problem and don't want to go through all the
    legacy scripts if I can help it.

    Is there a problem in the redhat 9 perl distribution, or just a
    misunderstanding of something on my part?

    Here's a tiny script to show the problem:

    my $x = "this\n";

    open(F, ">/tmp/test.txt");
    print F "$x";
    close(F);

    open(F, "</tmp/test.txt");
    my lines = <F>;
    close(F);

    if ($x =~ /^\s*([^\s]+)/)
    {
    print "'$x' internal string matched OK\n";
    }
    else
    {
    print "'$x' internal string FAILED!\n";
    }

    for $x (lines)
    {
    if ($x =~ /^\s*([^\s]+)/)
    {
    print "'$x' file string matched OK\n";
    }
    else
    {
    print "'$x' file string FAILED!\n";
    }
    }

    - gordon
    gordon Guest

  2. #2

    Default Re: perlio problem? redhat 9, perl 5.8.0

    [email]gordonockham.be[/email] (gordon) wrote in message news:<2369e2ad.0306240806.142022a9posting.google. com>...
    > To make the script work you can add a binmode F after the second file
    > open, or you can change the [^\s]+ to [\S]+ or \S+. But the question
    > is, why are either of these things necessary? I don't understand the
    > fundamental cause of this problem and don't want to go through all the
    > legacy scripts if I can help it.
    As an update, I can run the legacy scripts without change with
    LC_ALL=POSIX
    in the environment. But I still don't understand why it's necessary
    when I've some simple ASCII text (read: unchanged in UTF8 encoding vs
    ASCII encoding) being read/written to a file, and matched against
    [^\s].

    Very mysterious. Any feedback much appreciated!

    - gordon
    gordon Guest

  3. #3

    Default Re: perlio problem? redhat 9, perl 5.8.0

    On Tue, Jun 24, gordon inscribed on the eternal scroll:

    (well, no-one seems to have offered an answer, so I suppose I might
    try...)
    > The weird thing is that with a 5.8.0 compiled from source with default
    > settings, both matches work, which is what we'd expect.
    I don't see any logical reason why it would not work, so I'd rate it
    prima facie as a bug in the particular implementation that was
    giving the problem.

    Sorry, I'm not in a position to reproduce your error, so I'm neither
    confirming nor denying your report - just saying that on the basis of
    what you reported, it does seem like a bug.
    > Here's a tiny script to show the problem:
    [works for me, on several different platforms, but I didn't have the
    specific one you mentioned]

    (I think you'd need to report the release details of the RPM,
    the output of perl -V and so forth, to make it a proper bug report.)

    As you rightly say: with all of the characters involved being
    us-ascii, there shouldn't be any difference. Could it be that for
    some bizarre reason one of them got "upgraded" to unicode, and the
    other didn't, and they were then reported as not matching? But I
    might be talking rowlocks - it needs someone who understands the
    internals.
    Alan J. Flavell Guest

  4. #4

    Default Re: perlio problem? redhat 9, perl 5.8.0

    "Alan J. Flavell" <flavellmail.cern.ch> wrote in message news:<Pine.LNX.4.53.0306261459170.6298lxplus090.c ern.ch>...
    > On Tue, Jun 24, gordon inscribed on the eternal scroll:
    >
    > (well, no-one seems to have offered an answer, so I suppose I might
    > try...)
    >
    > > The weird thing is that with a 5.8.0 compiled from source with default
    > > settings, both matches work, which is what we'd expect.
    >
    > I don't see any logical reason why it would not work, so I'd rate it
    > prima facie as a bug in the particular implementation that was
    > giving the problem.
    >
    > Sorry, I'm not in a position to reproduce your error, so I'm neither
    > confirming nor denying your report - just saying that on the basis of
    > what you reported, it does seem like a bug.
    >
    > > Here's a tiny script to show the problem:
    >
    > [works for me, on several different platforms, but I didn't have the
    > specific one you mentioned]
    >
    > (I think you'd need to report the release details of the RPM,
    > the output of perl -V and so forth, to make it a proper bug report.)
    >
    > As you rightly say: with all of the characters involved being
    > us-ascii, there shouldn't be any difference. Could it be that for
    > some bizarre reason one of them got "upgraded" to unicode, and the
    > other didn't, and they were then reported as not matching? But I
    > might be talking rowlocks - it needs someone who understands the
    > internals.
    Thanks for your comments!

    Yeah, it looks like a bug to me the more I look at it. There's no
    reason,
    unicodedness or otherwise, that a match using [^\s] fails, and using
    [\S]
    or \S works. The printout of the strings that occurs in the test
    script
    show good text so nothing's obviously out of whack. Oh and, as you
    point out,
    it runs fine on lots of systems.

    FYI this was a pristine installation of redhat 9 inside of vmware.
    I'd not upgraded the perl or anything when I got the problem. The
    perl -V is attached to the end of this message in case someone can say
    "my god, why did they use *those* options" :) -- I'll report a bug to,
    errr, redhat or perl.

    It would be good though to have confirmation from someone else who can
    run this
    on a pristine redhat 9 with no LC_ALL=POSIX or C in their environment.

    perl -V:Summary of my perl5 (revision 5.0 version 8 subversion 0)
    configuration:
    Platform:
    osname=linux, osvers=2.4.20-2.48smp,
    archname=i386-linux-thread-multi
    uname='linux str'
    config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -g
    -Dmyhostname=localhost -Dperladmin=rootlocalhost -Dcc=gcc -Dcf_by=Red
    Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
    -Dvendorprefix=/usr -Dsiteprefix=/usr
    -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads
    -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db
    -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
    -Dinstallusrbinperl -Ubincompat5005 -Uversiononly
    -Dpager=/usr/bin/less -isr'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef'
    useithreads=define usemultiplicity=
    useperlio= d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=un uselongdouble=
    usemymalloc=, bincompat5005=undef
    Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
    -DDEBUGGING -fno-strict-aliasing -I/usr/local/include
    -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
    -DDEBUGGING -fno-strict-aliasing -I/usr/local/include
    -I/usr/include/gdbm'
    ccversion='', gccversion='3.2.2 20030213 (Red Hat Linux 8.0
    3.2.2-1)', gccosandvers=''
    gccversion='3.2.2 200302'
    intsize=e, longsize= , ptrsize=p, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define,
    longdblsize=12
    ivtype='long'
    k', ivsize=4'
    ivtype='long'
    known_ext, nvtype='double'
    o_nonbl', nvsize=, Off_t='', lseeksize=8
    alignbytes=4, prototype=define
    Linker and Libraries:
    ld='gcc'
    l', ldflags =' -L/usr/local/lib'
    ldf'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
    perllibs=
    libc=/lib/libc-2.3.1.so, so=so, useshrplib=true, libperl=libper
    gnulibc_version='2.3.1'
    Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef,
    ccdlflags='-rdynamic
    -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC'
    ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s
    Unicode/Normalize XS/A'


    Characteristics of this binary (from libperl):
    Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
    USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
    Locally applied patches:
    MAINT18379
    Built under linux
    Compiled at Feb 18 2003 22:19:53
    INC:
    /usr/lib/perl5/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/5.8.0
    /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.0
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/5.8.0
    gordon Guest

  5. #5

    Default Re: perlio problem? redhat 9, perl 5.8.0


    In article <2369e2ad.0306240806.142022a9posting.google.com >
    [email]gordonockham.be[/email] (gordon) wrote:
    >
    >
    > I'm having some problems running a bit of legacy perl code on a newly
    > installed redhat 9. With the perl 5.8.0 that comes with redhat 9, the
    > match against the string literal works, the match against the same
    > string read from a file fails.
    Gordon,

    I think you have saved me from possible insanity!

    I've been trying to isolate a problem with an INN News Server running
    on Redhat9. There is a reporting tool called innreport that fails on
    my system as the line read is not caught by a regex. If I define it
    as a string literal, then the line is processed quite correctly.
    This is on an out-of-the-box installation.

    It seems that Redhat 9 certainly does have a fairly serious bug.
    Muttley Guest

  6. #6

    Default Re: perlio problem? redhat 9, perl 5.8.0

    Muttley wrote:
    > In article <2369e2ad.0306240806.142022a9posting.google.com >
    > [email]gordonockham.be[/email] (gordon) wrote:
    >
    >>
    >>I'm having some problems running a bit of legacy perl code on a newly
    >>installed redhat 9. With the perl 5.8.0 that comes with redhat 9, the
    >>match against the string literal works, the match against the same
    >>string read from a file fails.
    >
    >
    > Gordon,
    >
    > I think you have saved me from possible insanity!
    >
    > I've been trying to isolate a problem with an INN News Server running
    > on Redhat9. There is a reporting tool called innreport that fails on
    > my system as the line read is not caught by a regex. If I define it
    > as a string literal, then the line is processed quite correctly.
    > This is on an out-of-the-box installation.
    >
    > It seems that Redhat 9 certainly does have a fairly serious bug.
    You are getting bit by RedHat's half-assed implementation of unicode.
    There is a "magic" environment variable which can be set to suppress the
    (mis)behavior. Check either the RH9 release notes or possibly one of
    the RedHat-related Usenet groups.

    Steven N. Hirsch Guest

  7. #7

    Default Re: perlio problem? redhat 9, perl 5.8.0

    On Wed, Jul 23, Steven N. Hirsch inscribed on the eternal scroll:
    > You are getting bit by RedHat's half-assed implementation of unicode.
    AIUI, this would have no effect except for the fact that 5.8.0
    trustingly responds to the relevant locale setting, e.g
    LANG=en_GB.UTF-8. We've been told that 5.8.1 won't do that.
    > There is a "magic" environment variable which can be set to suppress the
    > (mis)behavior.
    As far as I understand it, this is about the *default* behaviour of
    Perl 5.8.0 in assuming utf-8 in response to the the relevant locale.
    The usual workaround seems to be to change the environment settings to
    remove the reference to utf-8 (e.g change LANG=en_GB.UTF-8 to just
    en_GB), but AFAICS that isn't the only approach (and might have
    unexpected consequences elsewhere?).

    If in fact Perl is getting fed with iso-8859-1 -coded stuff, and if
    you tell it that you're doing so explicitly, it should work fine,
    irrespective of the locale setting, no?

    The fact is that no text-type data stream is complete without knowing
    its character coding. That fact has often been conveniently ignored
    in the past, but it's becoming increasingly important, and this is
    just one of the symptoms of its importance. I've only been saying "I
    told you so" since about 1994... (although the historical record shows
    that I've been interested in this topic since at least the mid 1960's,
    as testified by my STANTEC ZEBRA program for converting between
    Mercury Code and Murray Code aka IA#2 - two popular 5-bit character
    codes of that time ;-).

    Discussion suggests that there are bugs in the support for utf-8 in
    the version of Perl that's packaged with RH9, but if you're not using
    utf-8 then that shouldn't matter. The important thing is to clue-in
    the software, by one or other applicable means, to the fact that
    you're not really feeding it utf-8.

    At least I think that's right. Corrections welcomed.
    Alan J. Flavell Guest

Similar Threads

  1. perl install on redhat 9
    By Rick Bragg in forum PERL Beginners
    Replies: 1
    Last Post: October 10th, 04:36 PM
  2. Problem installing Perl-RPM module on a RedHat 9.0
    By Steve Houle in forum PERL Modules
    Replies: 1
    Last Post: September 24th, 06:25 PM
  3. perl 5.8.0 failed some locale tests on redhat 9
    By trwww in forum PERL Miscellaneous
    Replies: 1
    Last Post: August 18th, 09:57 PM
  4. CGI.pm problem under Redhat Linux 9.0 (perl-5.8.0)
    By marmot101 in forum PERL Miscellaneous
    Replies: 5
    Last Post: July 28th, 11:30 PM
  5. How to read and write serial port using PERL in REDHAT 8.0
    By Bryan Castillo in forum Perl / CGI
    Replies: 1
    Last Post: June 24th, 06:40 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139