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

What triggers the behaviour ?
I have (I think) the same build of perl as you - namely the x64 build of perl-5.10.1 (build 1006), and I get that annoying behaviour only if I open the cpan shell but no compiler can be found (because I forgot to first run the batch file that will make it visible).

If a compiler is not visible, the shell immediately changes color, and the download of MinGW automatically starts. (I suspect it's the 32-bit MinGW, too, which won't work with this build of perl anyway). I had assumed that ActiveState settings (not CPAN.pm) was responsible for all of this as the behaviour does not arise with perl-5.10.1 built from official perl 5.10.1 source .... but I haven't gone digging for the cause. (There is currently quite a bit of ActiveState-specific stuff built into ActivePerl.)

I certainly don't get any of those ansi escapes you reported, possibly because my $ENV{TERM} is set to dumb, as already suggested by Anonymous Monk. Not sure if that's an option for you, but it may help if you're open to it.

I take it you're running the cmd.exe shell.

Cheers,
Rob
  • Comment on Re^3: They've fscked with CPAN.pm again

Replies are listed 'Best First'.
Re^4: They've fscked with CPAN.pm again
by BrowserUk (Patriarch) on Sep 11, 2009 at 03:30 UTC
    I get that annoying behaviour only if I open the cpan shell but no compiler can be found

    Thanks! That is indeed the trigger. If I switch to a session with the compiler configured and the behaviour disappears. Another bloody stupid decision. Now I'll have to start a compiler session even if I just want to check the latest versions of my packages.

    And the visible escape sequences happened only after I tried Anonymonk's o conf colorise_output undef.

    But the stuff I've posted here doesn't show how bad it really is. I use white background, but they set it black. But not the whole thing, just what they print, so you end up with the mess of nearly invisble red and green text on a ragged-edged black background surrounded by white.

    As for the distinction between "ActiveState settings (not CPAN.pm) was responsible", the who doesn't really matter to me, I just wanted turn it off.

    $ENV{TERM} is set to dumb, Not sure if that's an option for you, No. I have other software that uses that standard environment variable. Using it to disable this idiocy is not an option.

    c
    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.
      Apparently it is an experimental feature, yup, idiotic to turn it on by default

      Thanks! That is indeed the trigger. If I switch to a session with the compiler configured and the behaviour disappears. Another bloody stupid decision. Now I'll have to start a compiler session even if I just want to check the latest varsions of my packages.

      Wait, you're annoyed by the color and not by having to press Ctrl-C, setup your compiler and relaunch cpan?

        you're annoyed by the color

        I'm annoyed that the colorisation doesn't repect my existing setup.

        If they changed the foreground color leaving my existing background intact (subject to no white-on-white scenario), I would probably have said "That's cool!" and used it.

        I might have even lived with them changing the background color, so long as they set the background color of the entire screen so you don't end up with this red or green on black in a sea of white, which is completely unreadable. (Well, maybe!)

        I'm annoyed that when you quit, they do not restore my originals setting. This is trivial to implement.

        I'm annoyed that there is no simple way to turn it off.

        I'm annoyed that this experimental feature is on by default, rather than opt-in.

        having to press Ctrl-C

        Hitting ^C isn't enough. Because they don't restore the original settings, once you've left cpan, you have to reset your colors and clear the screen before you can read what you've typed.

        Complicated further by the fact that I use different colors for different types of session--32-bit perl; 64-bit perl; 32-bit compiler; 64-bit compiler; debug builds; release builds. once they've messed with things, I then have to remember what the appropriate values are to restore them. Or throw away the session along with any information buffered on the screen amd in the session history buffers and start a new one.

        and not by ..., setup your compiler and relaunch cpan?

        I'm not quite sure why you think that doesn't annoy me? The sentence preceding the one you've quoted is a fairly strong indication that I'm not too happy about that either.

        In the end, the provision of a simple color [on|off] command (with the default off!), would be just so easy to implement and far better than the current 10 steps. (Which don't even work!)


        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.
Re^4: They've fscked with CPAN.pm again
by Anonymous Monk on Sep 11, 2009 at 03:06 UTC