Skip Menu |

This queue is for tickets about the ANSIColor CPAN distribution.

Maintainer(s)' notes

This queue is obsolete. Please use the Term-ANSIColor queue instead.

Report information
The Basics
Id: 44807
Status: rejected
Priority: 0/
Queue: ANSIColor
People
Owner: Nobody in particular
Requestors: RIVY [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Sun Apr 05 16:58:41 2009 RIVY [...] cpan.org - Ticket created
Subject: Use Win::Color::ANSI for $^O eq 'MSWin32' systems?
I be pleased if you'd consider adding use of the ANSI emulator module 'Win::Color::ANSI' if it's installed so that I don't have to include it manually. I'm a bit tired of writing aliases to load the module when I want color for my cmd or tcc shell (such as 'alias cpan=perl -MWin32::Color::ANSI -MCPAN -e shell'). Anyway, thanks for the consideration. - Roy
  Sun Apr 05 22:43:50 2009 rra [...] stanford.edu - Correspondence added
Subject: Re: [rt.cpan.org #44807] Use Win::Color::ANSI for $^O eq 'MSWin32' systems?
Date: Sun, 05 Apr 2009 19:43:32 -0700
To: bug-ANSIColor [...] rt.cpan.org
From: Russ Allbery <rra [...] stanford.edu>
"Roy Ivy III via RT" <bug-ANSIColor@rt.cpan.org> writes: Show quoted text
> I be pleased if you'd consider adding use of the ANSI emulator module > 'Win::Color::ANSI' if it's installed so that I don't have to include it > manually. I'm a bit tired of writing aliases to load the module when I > want color for my cmd or tcc shell (such as 'alias cpan=perl > -MWin32::Color::ANSI -MCPAN -e shell').
Could you explain what this module is, what it's for, and how Term::ANSIColor would use it? -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  Sun Apr 05 22:43:51 2009 The RT System itself - Status changed from 'new' to 'open'
  Mon Apr 06 10:51:47 2009 RIVY [...] cpan.org - Correspondence added
Subject: Use Win32::Console::ANSI ANSI emulator?
On Sun Apr 05 22:43:50 2009, rra@stanford.edu wrote: Show quoted text
> "Roy Ivy III via RT" <bug-ANSIColor@rt.cpan.org> writes: >
> > I be pleased if you'd consider adding use of the ANSI emulator module > > 'Win::Color::ANSI' if it's installed so that I don't have to include it > > manually. I'm a bit tired of writing aliases to load the module when I > > want color for my cmd or tcc shell (such as 'alias cpan=perl > > -MWin32::Color::ANSI -MCPAN -e shell').
> > Could you explain what this module is, what it's for, and how > Term::ANSIColor would use it?
On Sun Apr 05 22:43:50 2009, rra@stanford.edu wrote: Show quoted text
> "Roy Ivy III via RT" <bug-ANSIColor@rt.cpan.org> writes: >
> > I be pleased if you'd consider adding use of the ANSI emulator module > > 'Win::Color::ANSI' if it's installed so that I don't have to include it > > manually. I'm a bit tired of writing aliases to load the module when I > > want color for my cmd or tcc shell (such as 'alias cpan=perl > > -MWin32::Color::ANSI -MCPAN -e shell').
> > Could you explain what this module is, what it's for, and how > Term::ANSIColor would use it?
Sorry, late night and I mistyped it... it's actually Win32::Console::ANSI. Win32::Console::ANSI is an ANSI emulator [see homepage @ http://www.bribes.org/perl/wANSIConsole.html ; CPAN Module page @ http://search.cpan.org/~JLMOREL/Win32-Console-ANSI/lib/Win32/Console/ANSI.pm ]. Since the recent command shells (cmd.exe and alternate shells like tcc) for Windows don't have an ANSI driver available, I'm using this to provide the color driver support for your widely used Term::ANSIColor module. It only needs a module load to provide the emulator support. Currently, I'm using "set PERL5OPT=-MWin32::Console::ANSI" to load the driver, but I'd like to remove the weight from all my other modules which don't have/need color support. Aliases (eg, "doskey cpan=perl -MWin32::Console::ANSI -MCPAN -e shell $*") also work but are kludgy not easily applied to all scripts. I was thinking maybe using an %ENV{} variable like TERM_ANSICOLOR_ANSIEMULATOR (eg, "set TERM_ANSICOLOR_ANSIEMULATOR=Win32::Console::ANSI". Then, your module would load the ANSI emulator module when use'd if it's available (or warning if not available). Thanks for the response. - Roy
  Mon Apr 06 10:53:40 2009 RIVY [...] cpan.org - Subject changed from 'Use Win::Color::ANSI for $^O eq 'MSWin32' systems?' to 'Use Win32::Console::ANSI for $^O eq 'MSWin32' systems?'
  Mon Apr 06 14:54:12 2009 rra [...] stanford.edu - Correspondence added
Subject: Re: [rt.cpan.org #44807] Use Win32::Console::ANSI ANSI emulator?
Date: Mon, 06 Apr 2009 11:14:18 -0700
To: bug-ANSIColor [...] rt.cpan.org
From: Russ Allbery <rra [...] stanford.edu>
"Roy Ivy III via RT" <bug-ANSIColor@rt.cpan.org> writes: Show quoted text
> Currently, I'm using "set PERL5OPT=-MWin32::Console::ANSI" to load the > driver, but I'd like to remove the weight from all my other modules > which don't have/need color support. Aliases (eg, "doskey cpan=perl > -MWin32::Console::ANSI -MCPAN -e shell $*") also work but are kludgy not > easily applied to all scripts. I was thinking maybe using an %ENV{} > variable like TERM_ANSICOLOR_ANSIEMULATOR (eg, "set > TERM_ANSICOLOR_ANSIEMULATOR=Win32::Console::ANSI". Then, your module > would load the ANSI emulator module when use'd if it's available (or > warning if not available).
I'm wondering if there's any need to make it optional or if I should just always load that module if $^O is Win32 and that module exists. Is there a drawback to having it loaded? -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  Thu Apr 09 14:14:36 2009 RIVY [...] cpan.org - Correspondence added
On Mon Apr 06 14:54:12 2009, rra@stanford.edu wrote: Show quoted text
> "Roy Ivy III via RT" <bug-ANSIColor@rt.cpan.org> writes: >
> > Currently, I'm using "set PERL5OPT=-MWin32::Console::ANSI" to load the > > driver, but I'd like to remove the weight from all my other modules > > which don't have/need color support. Aliases (eg, "doskey cpan=perl > > -MWin32::Console::ANSI -MCPAN -e shell $*") also work but are kludgy not > > easily applied to all scripts. I was thinking maybe using an %ENV{} > > variable like TERM_ANSICOLOR_ANSIEMULATOR (eg, "set > > TERM_ANSICOLOR_ANSIEMULATOR=Win32::Console::ANSI". Then, your module > > would load the ANSI emulator module when use'd if it's available (or > > warning if not available).
> > I'm wondering if there's any need to make it optional or if I should just > always load that module if $^O is Win32 and that module exists. Is there > a drawback to having it loaded? >
Sorry for the delayed reply. As I'm only an interested user not the module author, take my code comments with a grain of salt. But, in looking at the Win32::Console::ANSI install code, it only installs on MSWin32 systems so you can probably skip the "$^O eq 'MSWin32'" check and just do an "eval { use Win32::Console::ANSI; }" in your initialization code. The Win32::Console::ANSI module is transparent, requiring only a 'use'. And I don't see any reason why the module would cause any problems for those programs using your module. Personally, I'd be happy if the Win32::Console::ANSI module was just always included if present, however I'm always a bit leary of module interactions therefore my initial %ENV{} suggestion. But again, on balance, I think if a user has installed the Win32::Console::ANSI module, that's reasonable defacto proof that they want it used and is good DoWhatIWant practice. The combination of the two modules does play well with CPAN on my various Windows installations (various XP and VISTA flavors). I'm not sure what other modules use Term::ANSIColor and haven't tested beyond CPAN. (I'm happy to do so if you have a few modules/scripts you'd like me to test.) So, my vote is yes, just include it if present on the system. Thanks again for your attention. - Roy
  Mon Dec 28 20:01:06 2009 RRA [...] cpan.org - Correspondence added
I queried perl5-porters about automatically loading Win32::Console::ANSI and got strong objection, on the grounds that Term::ANSIColor should be a lower-level module and shouldn't change the console settings.  The feeling seemed to be that higher-level applications, such as the CPAN shell, should arrange for it to be loaded themselves.

I'm rejecting this bug accordingly, but I think bugs against any other Perl applications you run into that don't arrange for this to be loaded on Windows are appropriate.
  Mon Dec 28 20:01:09 2009 RRA [...] cpan.org - Status changed from 'open' to 'rejected'