Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Red Hat

Perl

Schwern

here

More on Linux

Also by pudge

Red Hat Updates to 5.6.1

posted by pudge on 2002.03.06 8:22   Printer-friendly
Linux
Schwern writes "Chip Turner, maintainer for Red Hat's Perl distribution, has just announced that an official RPM for perl 5.6.1 is finally available! Previously Red Hat only shipped perl 5.6.0. The relevent Red Hat Errata is found here. Just in time for 5.8.0. ;)"
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Red Hat Updates to 5.6.1 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I recently installed RedHat 7.2 on my laptop. I was pretty upset to find 5.6.0 installed, seeing as 5.6.1 has been out for (what seems like) ages. On top of this, I noticed a problem with some of my network code on 7.2, and I've documented the problem and solution here [itcarlow.ie].
    • Interesting. I looked at your sample code. Have you tried stepping this through the debugger? My guess is that there's a warning generated on that line.

      Put a permanent watch on $! and $@ and see if anything happens. Perhaps wrap it in an 'eval' as well. Please let me know what happens - we're running on RH 7.2 here as well for some machines.

      • Wow! That was a fast response!

        Thanks for the suggestions. I will do what you suggest.

        Actually I'm pretty sure the assignment to the '$from_who' variable (as a result from the 'recv' call) is redundant. As I'm using TCP, the connection is already established, so it makes no sense to ask 'recv' to identify the other end of the connection, as the call to 'accept' has aready done this. It does make sense when using UDP, however. Thanks again.

      • To my undying shame, I had to read 'man perldebug' to remind myself how to use the debugger ...

        Now, wrapping the code within an 'eval' had no effect - it still died with the same error message. Note - surprisingly - that the code that contained the 'eval' died, not the evaled code (which was very strange and unexpected). The program was killed by RedHat! :-)

        I then ran the original code through the debugger, with watches on $@ and $!, as you suggested. The code died again with the same message, with the

        • Ah, yes. Ye 'ol "Illegal Seek" warnings. That and "Bad File Descriptor" are my favorite warnings, especially since no one in clpm can ever explain them and there's no way to step into core functions.

          My *guess* is that there's some difference in socket.h on RH 7.2 that's causing that problem. If you're feeling particularly frisky, you could look into it. :)

          • Curious I may be, frisky I'm not. ;-)

            Actually, I'm exchanging e-mails with Chip Turner in an attempt to "resolve" the issue. I'll report back to this 'thread' if anything comes of this.

            • Chip Turner at RedHat has tracked down the problem. As was suspected, my code incorrectly assigned the result from recv to the $from_who variable. Here's the contents of the e-mail from Chip:

              Hey Paul,

              I've traced down the problem. recvfrom isn't required by the UNIX98 spec to populate the from fields for connection-oriented sockets (in this case, TCP). I've confirmed that this is standard behavior in the default Linux 2.4 kernel.

              The man page for recvfrom (which is what Perl's recv ends up using, as

          • Illegal Seek (Score:2, Interesting)

            by pne (661)
            IIRC, "illegal seek" sometimes comes from checking $! when you have no business doing so (that is, when the operation you just completed did not signal an error, such as through its return code).

            ISTR reading something about how the stdio innards do some trickery to find out whether a file descriptor is connected to a TTY or something, and that this can result in the errno getting set to "illegal seek" -- but that this "error" is expected in that context and is therefore not passed on as an error return val
            --

            -- 
            Esli epei eto cumprenan, shris soa Sfaha.
            Aettot ibrec epesecoth, spakhea scrifeteis.

  • I never use the system Perl (Score:4, Insightful)

    by jdavidb (1361) on 2002.03.06 13:25 (#5532) Homepage Journal

    I love RedHat 7.[12]. In fact, my response after a day of using RedHat 7.1 was, "I'm getting rid of my Macintosh." The system is well integrated, pleasant to use, and had all the software anyone else in my family might want.

    That said, I never use the system Perl on any machine. If there's a Perl that came with the OS in /usr/bin, I leave it alone. I don't install modules with it, I don't upgrade it, and I don't program with it. All my programs start with #!/usr/local/bin/perl5.6.1 so they are hardwired to the exact Perl installation I wrote them with and won't break on an upgrade.

    I have found installing modules with a vendor supplied Perl is often difficult, although I think the situation has gotten better. I would never want to be in a situation where I decided to upgrade /usr/bin/perl and broke a vendor-supplied program, either. And finally, if I move my program to a machine with an older (or newer) Perl in /usr/bin, it should just work, and the only way I can ensure that is by personally installing 5.6.1 in the location I want it (/usr/local/perl561 with symlinks from /usr/local/bin). I routinely use newer features without realizing they are new (my $fh; open($fh, "file"), for example), so this policy makes sense for me.

    So I'm thrilled RedHat upgraded, because that means I can trust any Perl programs they include more, but it won't affect my daily work as much as one might expect.

    To us on the fasttrack (those who install versions like 5.7.3 and 5.8.0-rc1), RedHat seems light-years behind. However, it takes time to do real integration testing to verify that everything else included with RedHat and based on Perl still works with the new version. Sure, we're convinced it does, but the corporate world wants it tested, and I'd hate to have one mistake leave people who only see RedHat's packages saying, "Perl has bugs." That integration testing it what makes RedHat better than doing it yourself [linuxfromscratch.org], at least for some purposes. So, a commercial distro can always be expected to lag behind, sometimes dramatically, not just with Perl but also with the kernel, python, and what-have-you.

    When did Debian upgrade to 5.6.1? I'm thinking it was actually quite recently.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • > When did Debian upgrade to 5.6.1? I'm thinking it was actually quite recently.

      "Depends" :)

      Debian is actually four concurrent distributions: security, stable, testing and unstable. Each distribution is a tradeoff between stablity and up-to-dateness. Packages flow from unstable to testing and down to stable.

      Perl 5.6.1 entered Debian unstable on May 21st, 2001. If I recall correctly it went into the testing distribution shortly after that and has been there since. It has yet to reach stable (whic

      • Debian is actually four concurrent distributions: security, stable, testing and unstable.

        Security isn't a distribution actually. If you must, call it a component of stable. Security upgrades are included in proposed-updates which get folded into stable every now and then.

        Perl 5.6.1 will be included in stable when Debian 3.0 (woody) releases. With some luck that will be sometime this millenium, and with truckloads of luck even before 5.8.0 sees the light of day.

    • If you're brave, you can go through the modules that came with the distribution. Get those for your 5.6.1 installation in /usr/local. Then, in a piece of bold genious, mv /usr/bin/perl /usr/bin/perl.junk ln -s /usr/local/bin/perl /usr/bin/perl If the Gods smile upon thee, you might find yourself with a gorgeous new 5.6.1 system. However, I doubt that'll work in the highly integrated modern distributions. Never know, tho. Shouldn't be unbootable if I'm wrong. A simple rm /usr/bin/perl mv /usr/bin/perl.ju
  • At one point RedHat had a CD of RPMs for Perl modules; it was called the DMA "Developer Module Archive" and there was one for RedHat 7.1. I can't find the same for 7.2 or for this new update with Perl 5.6.1. Can anybody point me to the RPMs? (I've installed perl modules by hand, but I prefer RPMs for version tracking.)

    Thanks,
    Leigh.
  • Real nice. Now if there were only a corresponding update to mod_perl... =)
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.