Thanks Ken. I have not attempted to submit pull requests to Luis (he's the
ruby on windows guy), but who knows, maybe he'll merge them? Couldn't hurt
to try.
I'm thinking it would be better to ship with color support that works for
cmd.exe rather than no color support? Or do you think most people will try
to run puppet in powershell, in which case we could default color to
false...
Thoughts?
Josh
On Thu, Apr 5, 2012 at 7:51 AM, Ken Barber <k...@puppetlabs.com> wrote:
> So some gotchas I've hit using win32console that I also noticed when
> doing this in Facter:
>
> * The colors in Powershell differ from Command Prompt. This only
> affects the range in non-bright colors as I described before (0-7).
> win32console doesn't do anything about this it seems. My fix was just
> to use the intense colors for Windows (8-15).
> * The background isn't preserved when you just set a foreground color,
> I had a workaround that grabs the current color using the win32api and
> masked it on the color you desired - but it seems if you don't define
> a background win32console sets it to black. You can see this with the
> Powershell output on the right best.
>
> I've attached some screenshots. First one is the difference between
> powershell & dos, and I've also got a chart of numbers -> colors ...
> on the left is Command Prompt, on the right is Powershell - I hope you
> can see the differences. Basically it looks like there are differences
> for the secondary colors 3, 5 & 6 (cyan, magenta & yellow).
>
> I can't help but think that these problems should be solved in
> win32console. Has anyone reached out to this guy yet - to see if he'll
> take patches?
>
> ken.
>
> On Wed, Apr 4, 2012 at 11:11 PM, Ken Barber <k...@puppetlabs.com> wrote:
> > Great - I'll adapt my solution based on this discussion, probably
> > borrowing heavily from is in Puppet. At the very least I can certainly
> > borrow the API and simply add my own semantic symbols to provide
> > scheme support similar to how I've done it now.
> >
> > I guess the only other question is about code re-use ... shared code
> > is often hard to solve when it comes to the Facter/Puppet
> > relationship. While I'd like to see us implement a similar solution,
> > there is obviously Puppet-isms in that code that wouldn't transfer
> > easily. Not to mention how we deal with such a shared library. I know
> > we had a similar debate over puppetlabs_spec_helper and using subtrees
> > ... but this being part of real code (not rspec) we can run into
> > distro specific library decomposition hassles.
> >
> > At the moment the library is simple so code duplication problems are
> > quite small, but this might grow. Does anyone have any preferences as
> > to how this should be dealt with? I haven't put any thought into it
> > yet myself to be honest.
> >
> > ken.
> >
> > On Wed, Apr 4, 2012 at 10:15 PM, Pieter van de Bruggen
> > <pie...@puppetlabs.com> wrote:
> >>
> >>
> >> On Wed, Apr 4, 2012 at 1:58 PM, Ken Barber <k...@puppetlabs.com> wrote:
> >>>
> >>> > Invoking Windows' native color support changes the color of the pen
> at
> >>> > that
> >>> > particular moment, tightly coupling the colorization time with output
> >>> > time.
> >>> > In Facter, this is less of a big deal, since you're effectively
> >>> > choosing to
> >>> > style content based on its type at output time. In Puppet,
> especially
> >>> > with
> >>> > the work done on the module tool (and moving forward into Telly),
> we're
> >>> > seeing a distinct need to decouple those processes. For example, if
> I
> >>> > want
> >>> > to colorize only version numbers in the module tool's output, a tight
> >>> > coupling means that I have to (in the worst case):
> >>> >
> >>> > * Decompose the output message on version number boundaries
> >>> > * Iterate over those "chunks" of the output
> >>> > * Print each "chunk" with an appropriate color
> >>> >
> >>> > If I decide to start coloring any other part of the output as well
> (say,
> >>> > module names), the problem gets more expensive.
> >>> >
> >>> > Injecting ANSI escape sequences into the string as a form of markup
> >>> > (inelegant as it is) gives us flexibility -- we could, in that same
> >>> > example,
> >>> > run a quick s///g and have colorized the string appropriately.
> While we
> >>> > could easily write our own handler to intercept those escapes on
> Windows
> >>> > and
> >>> > change the pen color at output time, that's exactly what libraries
> like
> >>> > ansicon and win32console are doing for us.
> >>>
> >>> Okay - I understand the need to store away variables and re-use them
> >>> later and the issues related to when you colorise them so I can see
> >>> your point.
> >>>
> >>> I guess using the color_print methodology does require a prior
> >>> decomposition that literally applies labels to sections of text. But
> >>> this was intentional I assure you.
> >>>
> >>> Of course you could do this in other ways as well, I originally
> >>> experimented with using labels in the string such as:
> >>>
> >>> print "#{t.color(:green)}My green text{#t.color(:reset)}"
> >>>
> >>> My goal here was to avoid having to have people enter the ANSI/SGR
> >>> codes themselves. But this wasn't going to work with the win32api - as
> >>> the method (t.color) was evaluated before the string was processed
> >>> :-). This could still work with win32console using ANSI escape
> >>> characters.
> >>>
> >>> I guess on a similar note to solve the scheme problem one could do
> >>> something like:
> >>>
> >>> print "#{t.color(:strings)}\"foobar\"#{t.color(:reset)}"
> >>>
> >>> Or some such. Then we can still replace these with the correct escape
> >>> codes in a central place - thus still achieving my scheme solution.
> >>>
> >>> ken.
> >>
> >>
> >> I think we're on the same page. The way Puppet::Util::Colors is
> implemented
> >> is in pursuit of the same goal. While we don't (yet) have semantic
> class
> >> names, we definitely *don't* want anyone to have to write their own
> escape
> >> codes.
> >>
> >> include Puppet::Util::Colors
> >>
> >> red_string = colorize :red, "this string is (#{ colorize :blue,
> 'mostly'
> >> }) red"
> >> puts colorize(:green, "--> #{red_string} <--")
> >>
> >> (When we have fleshed out our color vocabulary, it should be very
> simple to
> >> add semantic names to this module.)
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Puppet Developers" group.
> >> To post to this group, send email to puppet-dev@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> puppet-dev+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/puppet-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>
>
--
Josh Cooper
Developer, Puppet Labs
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
