Thu Jan 15 04:17:25 2015: Request 101554 was acted upon.
Transaction: Ticket created by ralesk
Queue: Win32-Console
Subject: Co-existence with non-Win32 environments
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ral...@cpan.org
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101554 >
The exported colour variables seem to cause some trouble if you're writing a
module that tries to work on both Win32 and normal ANSI sequence TTYs.
In my case, if we're under Win32, I use console functions to colour my output,
if we're under Linux, I just print to STDERR with escape sequences. However,
under `use strict`, the variables will not be defined and my module won't
compile because I cannot `use Win32::Console` (it is not possible to compile
even a stub on Linux, as the compiler says OS not supported). If I predefine
the variables (unconditionally, because if is a block, so I can't usefully put
a `my` declaration inside it of course), then importing Win32::Console won't
override them so all I get is black on black...
The solution seems to be to always refer to these variables with their full
names, ie. $Win32::Console::FG_YELLOW, which makes strict and Linux happy, and
still works on Windows.
I wonder if there's a better way than the current exporting of variables (`use
constant FG_YELLOW`?), or if Win32::Console could be made to compile to a stub
module on non-Win32 so it can be used unconditionally and just not get in the
way.
