Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • I agree that "Can't locate in @INC" is a very poor error message. For a new user is must be worse than meaningless and as an experienced user the handful of times that it has been useful to me (i.e. messed up paths and not missing modules) I could have figured out anyway with perl -V or similar.

    A Google search for Can't locate in @INC [] turns up 128,000.00 hits. That is a large number but even more telling is the wide range of forums that they appear in. The "@INC" message is clearly a hinderance to

  • Perl::Shell is a minimalist module and as such it would be easier to support and maintain, but I've been using Devel::REPL with great success as my command line perl.

    life is short
  • You really like to goad me to put my "evil hat" on. This is a crude example to show the concept -- it would need to be a bit more helpful and a bit more robust for real use.

    package Nice;
    use strict;
    use warnings;
    no warnings 'once';

    *CORE::GLOBAL::require = sub {
      my $mod = shift;
      eval { CORE::require($mod) };
      if ($@) {
        if ( my ($mod) = $@ =~ /\ACan't locate (\S+)/ ) {
          $mod =~ s{/}{::}g;
          $mod =~ s{\.pm$}{};
          $@ = <

    • Also, maybe try to trap the file and line number where they tried to require the module?

    • Nice first hack though. Seriously.

    • It'd be nice if Padre detected this in its console output too - and automatically opened a CPAN GUI to help the user install the dependency (
  • But since lots of people don't use the command line (they hit Perl via a batch script or similar) now I might also need to hijack perl.exe entirely to deal with it (except that breaks things that do pass-through code to child Perl's for process isolation reasons).

    Eh, no, you don't have to patch perl.exe. Instead, put it in a module. Just like diagnostics [] does nothing but explaining warnings and errors better.

    You can load this module on the command line using -M, or you could set an environment variable like PERL5LIB, so it gets used in every Perl script that gets run from the batch file.

    • ... you don't have to patch perl.exe.

      If the executable supported localization and translation files, swapping in other error messages would be easier. (Replacing them entirely might not be as easy though.)

    • I can't load this module on the command line, as I am neither the person who wrote this code nor am I the person running this code.

      The people doing both the writing and the running are not on this website, and do not have the benefit of this suggestion (which is why any answer that involves eduction doesn't work in general).

      I can't modify the site perl script, because I'm only the vendor of the Perl distribution, not the site.

      And I'm a teensy bit dubious about PERL5LIB, one because it won't work under taint

      • So build Strawberry with -Dusesitecustomize, and put it in there. That's exactly what it's there for, and anyone who knows enough to know they don't want it can turn it off with the -f switch.
  • > I posit that there's a whole swath of people that don't hate Perl
    > for it's syntax, since they don't read all kinds of other ugly
    > languages they use day to day.
    > They hate it because running a typical Perl program as an
    > untrained user is hard when it works, and impossible to setup
    > when it is missing dependencies.

    So about the same as EVERY OTHER LANGUAGE. Python, Ruby and Java all have the same problem of not making it at all clear how to resolve missing dependencies. Certainly m

    • Perl doesn't even really make it clear there IS a missing dependency.

      It just says it can't load some file

    • The fact that so many other languages get it wrong does not excuse us for getting it worse.

      It *does* mean we have an opportunity, *if* we can get it right. And, given CPAN, we *can* get it right. All we need to do is send the right patch to the core maintainers, and convince them it's right. Alternatively, we could produce a module, and convince them to have the normal build process include that in a location that will normally get loaded in as core (maybe as sort of a 'usecorecustomize'ish type thing.)