in reply to Re^2: They've fscked with CPAN.pm again
in thread They've fscked with CPAN.pm again

Are you sure it is "opt out?" Or is this specific to a certain platform? I've never had any coloring in my terminal on any number of OS X and Linux flavors on any of the 15 or more versions of CPAN I've used the shell with; on the most recent version now and it's just plain terminal text.

Maybe some package changed the settings on you...? This is what mine shows (I had no idea the settings existed till reading your post)-

colorize_debug undef colorize_output undef colorize_print undef colorize_warn undef

Update: solution-wise, you can probably find and edit your CPAN/MyConfig.pm to remove the settings.

Replies are listed 'Best First'.
Re^4: They've fscked with CPAN.pm again
by BrowserUk (Patriarch) on Sep 11, 2009 at 02:48 UTC

    I'd never seen it before either until I recently upgraded to 5.10.1. Nothing else changed--in terms of environment settings etc.

    Upto and including 5.10.0 (AS1004), I was also blissfully unaware that there was even an option for this. After the upgrade, not only is everything inside the cpan shell unintellible, once you quit out, everything else is too because they fail to put things back how they were. Its just bad programming.

    And it rejects any attempts to achieve your settings:

    ←[32m cpan shell -- CPAN exploration and modules installation (v1.9402) Enter 'h' for help.←[0m cpan> o conf /color/ ←[32m$CPAN::Config options from ←[0m←[32m'C:\Perl64\ +lib/CPAN/Config.pm'←[0m←[32m:←[0m ←[32m←[0m ←[32m colorize_debug undef←[0m ←[32m colorize_output [undef]←[0m ←[32m colorize_print [green]←[0m ←[32m colorize_warn [red]←[0m ←[32m←[0m ←[32m←[0m cpan> o conf colorize_debug undef ←[32m colorize_debug [undef]←[0m ←[32mPlease use 'o conf commit' to make the config permanent!&#8 +592;[0m ←[32m←[0m cpan> o conf colorize_print undef Term::ANSIColor rejects color[undef]: Invalid attribute name undef at +C:\Perl64\lib/CPAN/Shell.pm line 1453 Please choose a different color (Hint: try 'o conf init /color/') colorize_print [undef]←[0m Term::ANSIColor rejects color[undef]: Invalid attribute name undef at +C:\Perl64\lib/CPAN/Shell.pm line 1453 Please choose a different color (Hint: try 'o conf init /color/') Please use 'o conf commit' to make the config permanent!←[0m Term::ANSIColor rejects color[undef]: Invalid attribute name undef at +C:\Perl64\lib/CPAN/Shell.pm line 1453 Please choose a different color (Hint: try 'o conf init /color/') ←[0m

    Bah humbug! Time to go a hacking again :(


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Does AS1004 mean Activestate? If so, I suspect it's their fault, cos I've not noticed this behaviour on any of the several perls I've built since 5.10.1 came out, on all kinds of different platforms.

      Or it's a Windows bug and it's not properly rendering colour codes. Have you loaded ANSI.SYS?

        "5.10.0 (AS1004)" is BrowerUK's shorthand for "ActivePerl 5.10.0, build 1004".

        Perl major version -- 1004 -- build number of that Perl version

        It's ActiveState's 4th or 5th build of Perl 5.10. It happens to be a build of 5.10.0, but the minor version isn't specified by the build number.

        1006 was their first build of 5.10.1.

        Does AS1004 mean Activestate?

        Hm. The CPAN testers don't know. Says it all.

        Have you loaded ANSI.SYS?

        There is no such thing on my system. And it hasn't been necessary for 10 years or more.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.