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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • So firstly, no guarentees if you have more than one Perl installed... no Perls really live together well.

    Secondly, there's known issues in CPAN.pm.

    I recommend uninstalling the July strawberry and trying again with the new October release.

    http://strawberry-perl.googlecode.com/files/strawberry-perl-5.10.1.0.msi [googlecode.com]

    This has a new (dev) CPAN release that might fix your problem, and some updated Perl modules and C libraries that should (hopefully) make the installation much easier.

    Finally, yes, newbies are not REALLY meant to be using Strawberry Perl. The main audience for the current product design is Unix people who are stuck on Windows.

    January release should hopefully fix that finally.

    • I submit that almost anyone installing strawberry already has a perl, and likely more than 1.

      When I install strawberry, I have activestate, cygwin, and I tried building my own. And after that, I have an old strawberry in front of the new strawberry.

      A prominent set of warnings seems appropriate.

      • The way I solved that is as follows:

        I removed the Strawberry specific paths from the PATH environment variable. I then added an icon in the start menu to launch a console shell (cmd.exe), after prepending these paths to PATH first.

        One easy way to do that, is by making a BAT file with the following contents:

        @echo off
        path C:\strawberry\c\bin;C:\strawberry\perl\bin;%path%
        cmd

        But an IMHO nicer alternative is to just create a shortcut with this as the target:

        cmd.exe /k PATH=C:\strawberry\c\bin;C:\strawberry\pe

        • I just found there's a padre.exe file in the perl\bin directory, with the same modification time as padre.bat. Apparently they were built together. So that's why it doesn't need a console window...

        • Thanks much! I think I understand, and I will try that.

          In a previous version of strawberry (last one?), when padre tried to update, for me things choked due to failures in the toolchain of padre. Does this likely have to do with the path during the update of padre? (I think that happened before I have the opportunity to intervene...)

          It would be lovely for such advice as yours to be obvious to strawberry perl installers who encounter such problems.

          Thanks again! I love perl, though it can be trying at time

      • One of the things that I ran out of time for in October is checking the path for other perl interpreters and putting up warnings if neccessary ... I'm hoping to get it done for January.

        As for the PATH thing - we put ourselves in the system path because it is an "all-users" installation. (another thing for January that needs to be discussed is the possibility of making "all-users/current-user" selectable.) We DO try to be polite and put ourselves at the end of the system path (and the proposed "current-user"

        --
        The new Strawberry Perl for Windows has been released! Check http://strawberryperl.com for it.
        • All this information is good. And thanks for your work on SP, I love the idea.

          But the most important thing I am saying, is when I install SP, it should make obvious some of these issues, right in the faces of the novice installers (like me). I don't use IRC, but I do lurk on useperl.

          Maybe in the last install window, an "open install notes from c:\strawberry\INSTALL_strawberry.txt" checkbox with default checked...

    • It's good to see honest feedback with warts and all and a reasoned response. It's shows good maturity - it would be so easy to fly off the handle with a post like this.

      --
      -- "It's not magic, it's work..."
    • Almost every Windows server I use at work has three Perls installed - Activestate (which we run our code against), Oracle's Perl, and an HP version that comes with its server software. It appears mostly seemless, but it in the bad old days (probably 7-8 years ago), an upgrade of Oracle meant that it's Perl took preference over Activestate's and our code crashed and burned. I'm not sure if this is still an issue.