Using GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13) on OS X 10.9.5.

The .blink method does not work for me.

puts "Hello".blink just prints out regular text to the console.

One interpretation of GPL 2.0 has made it so that I am discouraged from using this gem. The Apache and MIT licenses encourage using libraries with less copy-left implications. Any chance of shifting?

Example

arg = ARGV[0]
puts arg.green

Result

RuntimeError: can't modify frozen String
    /home/hal/.gem/ruby/1.9.3/gems/colorize-0.6.0/lib/colorize.rb:95:in `colorize'
    /home/hal/.gem/ruby/1.9.3/gems/colorize-0.6.0/lib/colorize.rb:129:in `block (2 levels) in <class:String>'

Hi,

With the latest release, there are unexpected changes.

One was the removal of the question marks, recently fixed.

A second one is that String#magenta is no longer supported (and it was not advertised in the release notes).

And finally, I don't know what was the impetus to change the escape sequences, but they are not recognize by less, and now I get

^A^Bmy-message^A^B

displayed where, before the recent release, everything was displayed correctly. Just try ruby -e "require 'colorize'; puts 'foo'.magenta" | less -R to see the problem (or some other color if magenta does not work ;-).

The changes for readline (whose purple^H^Hoses are not entirely clear to me) seem to have many unexpected effects. It should probably be opted-in rather than mandatory.

Cheers.

If I do

res = "red".red
res.uncolorize

I will get a non-colored string. Which is what is expected.

But if I do

res = "red".red + "blue".blue
res.uncolorize

I will get a colored string where I would have expected to get a non-colored string.

I have tested this with several similar scenarios and always get this behavior. I have a use case where I need such a situation to work.

I color certain words which are concatenated in a multi-colored string. I then want to be able to conditionally apply the uncolorize operation to this string.

The difference between the GPL versions is large enough to be more clear in the gemspec. Please follow the spdx.org license format and say

"GPL-2.0+" as your README.rdoc specifices version or later. But note that the license you gave your code also says you need to have a COPYING file in your sources - and you don't.

please make a new release already using RUBY_PLATFORM instead of PLATFORM so this actually works on ruby 1.9

I'd like an option to rainbow-ize strings

Thanks

This is a feature request to make this gem support all 8-bit, i.e. 256 colors.

Ruby 1.8.7 (2011-12-28 patchlevel 357) [universal-darwin11.0].

>> require 'colorize'
=> true
>> require 'yaml'
=> true
>> s = 'haha'
=> "haha"
>> puts s.colorize(:background => :red)
haha
=> nil
>> s
=> "haha"
>> YAML.dump(s)
=> "--- !str \nstr: haha\n\"@color\": 9\n\"@mode\": 0\n\"@uncolorized\": !str \n  str: haha\n  \"@color\": 9\n  \"@mode\": 0\n"

I try

'test'.coloroze(:bold) - no effect
'test'.coloroze(:white).bold - become bold

What is a right way to do it?

Probably it generates wrong codes, this code prints bold:

puts "\033[1mSome Text"

Hi,
I noticed that on OSX, blink works in the default terminal but not in Iterm.

Very good work though!

@fazibear thank you for this excellent gem. It has been a mainstay in the ruby community and used by thousands of companies and projects. It is still being added as a dependency to new gems that are coming out now.

I see there hasn't been a release in a few years. This may be because that it is considered "feature complete", and no further releases are planned.

If so, can we put something at the top of the README to say something to that effect? Otherwise more PRs (which may take hours) may be opened which will never be used. Maybe a pointer to other gems in this space that are accepting changes (eg rainbow I believe).

Thanks again!

any chance we can get a git tag for the latest release that is put on rubygems?
Would appreciate it

We could use it like this:

>> require 'colorize'
=> true
>> 'hey'.blue
=> "\e[0;34;49mhey\e[0m"
>> 'hey'.blue.length
=> 17
>> 'hey'.blue.original_length
=> 3

In can implement it btw, just tell me what you think about it :)

I can not explain why, but after bundle updating to the latest colorize gem via konacha dependency, my test output is messed up. If I console into my Rails app using the different versions, here is what I see.

#0.7.3
>> "Ken".colorize(:green)
=> "\e[0;32;49mKen\e[0m"

#0.7.5
>> "Ken".colorize(:green)
=> "\e[greenmKen\e[0m"

However, if I just start an irb session and load the 0.7.5 colorize gem, all is fine. Do you have any ideas what would cause the discrepancy. There are no other gems that have a colorize method. Could there be something in this 0.7.5 release that has some non-deterministic behavior based on load order? TIA for your time.

We haven't heard back from the developer of colorize and the project looks like it has been abandoned.

I forked the repo and updated it with most of the pull requests from this repo.
Still need to test the STDOUT.isatty pull request.

You can find the updated gem here:
https://rubygems.org/gems/chromatic
https://github.com/AJ-Acevedo/chromatic

enjoy!

By convention, I am used to colorized applications suppressing colorization when sending the output to a pipe, unless I explicitly force colorization.

For example, in colors.js:

if (process.stdout && !process.stdout.isTTY) {
  return false;
}

Writing an app using colorize, I was surprised that colors were not suppressed when doing app > file.txt or app | cat. The color codes can cause problems in later processing stages.

I then turned colorization off for non-TTY output with:

String.disable_colorization(true) unless STDOUT.isatty

I'd like to propose that be the default behavior, with a way to force colors by choice in all cases.

The Free Software Foundation is no longer at 675 Mass Ave, Cambridge, MA.

Our new address is 51 Franklin Street, Suite 500, Boston, MA 02110.

You can confirm this for yourself here: http://www.fsf.org/about/contact/

Please update all references to our old address in your code so people can continue to contact us (we haven't been at the old address for more than a decade at this point)

Kind regards,

matt

Matt Lee
Campaigns Manager
Free Software Foundation

This behavior just appeared, I'm really not sure what's happening:

[4] pry(#<Beanshed::Logger>)> "foo".red
=> "\e[0;\e[31mfoo\e[0m;49mfoo\e[0m"

Will print a proper red string, followd by ;049m followed by the string again in white.

Any idea?

It would be great if we could set a colorized string without having to specify the colour.

Something like:

puts "hello world".colorize(:random)

and

puts "hello world".colorize(:next)

I've added this to my own application as a quick hack

module ColorStepper

  COLOURS = [:red, :light_red, :green, :light_green, :yellow, :light_yellow, :blue, :light_blue, :magenta, :light_magenta, :cyan, :light_cyan, :white, :light_white]

  module_function

  def enumerator
    @enumerator ||= COLOURS.each
  end

  def next
    begin
      enumerator.next
    rescue 
      enumerator.rewind
      retry
    end
  end
  
  def random
    COLOURS.sample
  end

end

I updated to 0.7.5 and Capistrano (sshkit) broke:
/usr/local/Cellar/ruby/2.1.5/lib/ruby/gems/2.1.0/gems/sshkit-1.6.0/lib/sshkit/color.rb:4:in `module:Color': uninitialized constant String::COLORS (NameError)

I downgraded to 0.7.3 and all is well.

I think this is a recent, but a really bad bug:

irb(main):001:0> puts "?".red

=> nil
irb(main):002:0> puts "?.".red
.
=> nil
irb(main):003:0> puts "!.".red
!.
=> nil
irb(main):004:0>

They sound like they might be the same thing.

Hey @fazibear, I'm working on verifying license compliance for GitLab right now and we use your gem in our application. You can see the relevant issue and discussion here.

Essentially, GitLab CE is licensed under the MIT Expat. We can't use a GPL'd gem without the application itself becoming GPL. Your gem and one other (which we're replacing) are the only things stopping us from ensuring compliance at the moment. Right now we have two options: replace/remove the gem or have the gem be relicensed.

Browsing through some of your other libraries, the newer ones seem to all be MIT, so that's definitely an option. Alternatively, you can use the LGPL if you'd like to keep the constraints of the GPL with the caveat that non-GPL applications can still link to the gem (assuming it's unmodified) without having to be GPL themselves.

The process of should be relatively simple. Since there are 9 contributors to the library, you'll need to get each of them to agree to relicense the code they've contributed (assuming it's still in the library and hasn't been replaced). You can read about Dolphin doing something like this (albeit at a much larger scale) here.

My understanding is that, for trivial contributions (e.g. only deleting code, not adding code, or just fixing spelling/grammar) they don't own copyright over any of the code, so you don't need them to agree. So that should cover AJ-Acevedo, josegonzalez, adie, damphyr, and Rakoth.

We'd need permission from satyap, you (fazibear), namusyaka, and frozzare (I won't @mention them so as not to bother them with notifications if you're uninterested in relicensing. If you are, we can notify them so they can comment).

If you're interested in doing this, we'd be happy to help if we can. If not, that's perfectly fine, we'd just like to know so we can move to another gem.

Best and thank you for your time,
Connor Shea

There seems to be an issue with the newline (\n) character in strings that get colorized. In the examples below, samples 001 and 003 are perfectly fine, whereas samples 002 and 004 contain control characters and appear in white.

I want to colorize just part of the string.
Is it possible?

SHA: f858d87

removed readme.rdoc also the copyright statement. Could you please include it into the new README.md?

I am using the library to colorize logs and it works great.

In other cases though I am reading logs from stdin through a pipe, and would like to strip the existing color codes and then parse the lines and then recolor and then print to stdout.

For example :

some_process_which_creates_colored_logs | another_process_which_reads_from_STDIN_the_colorized_log.rb`

and then:

another_process_which_reads_from_STDIN_the_colorized_log.rb
STDIN.each_line do |line|
  clean_line = line.strip_color_code_if_exists
  printer.print(clean_line.yellow) 
end

First of all, thanks a bunch for this wonderful Gem 👍

It does not seem to work with Rails 5.0.0.1 though:

[1] pry(main)> 'test'.red
NoMethodError: protected method `set_color_parameters' called for "\e[0;31;49mtest\e[0m":String
from /.../gems/colorize-0.6.0/lib/colorize.rb:105:in `colorize'

It'd be great if you could have a look at this. Many thanks.

Hey @fazibear

On your commit 9aa7038 [9aa7038],
you added support for readline, but that should be optional... i lost all my colors in the rail loggers..

I try to do it but it's not working...

#instance_methods.rb

def colorize(params)
  return self if self.class.disable_colorization

  scan_for_colors.inject(self.class.new) do |str, match|
    colors_from_params(match, params)
    defaults_colors(match)
    str << "(\001)?\033[#{match[0]};#{match[1]};#{match[2]}m(\002)?#{match[3]}(\001)?\033[0m(\002)?"
  end
end

......

def scan_for_colors
scan(/(\001)?\033\[([0-9;]+)m(\002)?(.+?)(\001)?\033\[0m(\002)?|([^(\001)?\033]+)/m).map do |match|
    split_colors(match)
 end
end

before this commit

after this commit

Do yoy have any solutions to fix it?

Bests

When using capistrano :
TypeError: no implicit conversion of Hash into String

Installing 0.7.3 fixes the issue.

Laravel

Been loving this gem for years! Unfortunately, also for years, I've kept writing "something".grey, only to end up in the sources again to remind myself that its called "light black" here. Is there any chance we could get #light_black aliased to #grey and #gray?

Hi, ruby geeks
When working with your gem, I needed additional functions. I created them and wrote an example to demonstrate.
The function, that get the real length (excluding the escape character) and the function of getting a "clean" string from "colorized" - the removal of color escapes components.
I believe these features will be useful not only for me.
Thank you for your attention.

Code example:

require 'colorize'

class String
    def remove_color!
        replace remove_color
        return self
    end

    def remove_color
        res = self.clone
        res[/�.+?m/] = '' while res.index '�'
        return res
    end

    def real_length
        return length - count('�') * 7
    end
end

a = 'hello'.red
puts "a: #{a.inspect}"
puts "real len #{a.real_length}"
puts "clear: #{a.remove_color}"
puts "a: #{a.inspect}"
a.remove_color!
puts "a: #{a.inspect}"

Return:

a: "\e[0;31;49mhello\e[0m"
real len 5
clear: hello
a: "\e[0;31;49mhello\e[0m"
a: "hello"

there's a duplicate method call add_color_alias(:grey, :light_black), when it is called on class ColorizedString this results on an error caused by check_if_color_available! "Colorize: color named :grey already exist!"

For example:

"Error Code: #{error.colorizer(:red)}".colorizer(:yellow)

I would want the code to still be red, with the rest of the text being yellow.

DS_Store stores information specific to a folder in MacOS. It is better ignored as it can be a potential cause of merge conflicts.

To reproduce:

require "colorize"
puts "test\r\e[Kx"
puts "test\r\e[Kx".red

Expected output:

x
x

Actual output:

x
[Kxt

This might be unfixable due to limitations of ANSI escape sequences; I have no idea.

The gem uses colorize method which is incompatible with the colored gem. Colorize is used by Konacha gem for javascript tests in headless mode. It'll be great if you can work something out with the developers of that gem.

Most modern terminals support true color with full RGB values ($COLORTERM == ‘truecolor’). I made an app that color-codes different programming languages, and when I started running out of Colorize's 16 colors, I looked around and discovered that there was a surprisingly simple way to colorize text and background--see below, String#color_text and String#color_bg.

Then I discovered that there are a few basic terminals that don't have $COLORTERM == ‘truecolor’, so I made my code (which had used Colorize) backwards-compatible with Colorize; I wrote my own String#colorize method. And then I decided to make that method work regardless of whether a console had $COLORTERM true or not. See below.

If Colorize incorporated this more advanced colorization, that would be awesome. Any interest?

module Colorize::InstanceMethods
  alias :old_colorize :colorize
end

class String
  def color_text(r, g, b)
    "\033[38;2;#{r};#{g};#{b}m#{self}\u001b[0m"
  end

  def color_bg(r, g, b)
    "\033[48;2;#{r};#{g};#{b}m#{self}\u001b[0m"
  end

  # Takes symbol with English color name, returns colored string.
  # Examples: "foo".colorize(:red) => returns red string.
  #           "foo".colorize(background: :blue) => returns blue background string.
  def colorize(color)
    if ENV["COLORTERM"]
      color.class == Symbol ?
        self.color_text(*RGB_CODES[color]) :
        self.color_bg(*RGB_CODES[color[:background]])
    else
      if color.class == Symbol
        color = COLOR_MAPPER.has_key?(color) ? COLOR_MAPPER[color] : color
        self.old_colorize(color)
      else
        color[:background] = COLOR_MAPPER.has_key?(color[:background]) ?
          COLOR_MAPPER[color[:background]] : color[:background]
        self.old_colorize(color)
      end
    end
  end

  RGB_CODES = {
    # Original "Colorize" gem colors, for backwards-compatibility.
    black:  [46, 52, 54],
    red:    [204, 0, 0],
    green:  [78, 154, 6],
    yellow: [205, 176, 48],
    blue:   [52, 101, 164],
    magenta:[117, 80, 123],
    cyan:   [6, 152, 154],
    white:  [211, 215, 207],
    light_black:  [85, 87, 83],
    light_red:    [239, 41, 41],
    light_green:  [158, 229, 90],
    light_yellow: [252, 233, 79],
    light_blue:   [114, 159, 207],
    light_magenta:[173, 127, 168],
    light_cyan:   [52, 226, 226],
    light_white:  [238, 238, 236],
    # New colors.
    free_speech_red:[169, 16, 0],     # Ruby
    festival:       [233, 212, 77],   # JavaScript
    denim:          [27, 132, 193],   # CSS
    tahiti_gold:    [233, 98, 40],    # HTML
    chateau_green:  [69, 181, 80],    # Bash
    malibu:         [93, 164, 221],   # SQL/PSQL
    echo_blue:      [163, 179, 198],  # C
    med_aquamarine: [98, 202, 175],   # C++
    carrot_orange:  [240, 148, 33],   # Java
    saffron:        [247, 191, 48],   # Python
    brown:          [165, 42, 42]     # Rust
  }

  # Mapping new color names to old names for use by Colorize gem.
  COLOR_MAPPER = {
    free_speech_red:  :red,           # Ruby
    festival:         :light_yellow,  # JavaScript
    denim:            :blue,          # CSS
    tahiti_gold:      :light_red,     # HTML
    chateau_green:    :white,         # Bash
    malibu:           :cyan,          # SQL/PSQL
    echo_blue:        :light_blue,    # C
    med_aquamarine:   :blue,          # C++
    carrot_orange:    :magenta,       # Java
    saffron:          :yellow,        # Python
    brown:            :red            # Rust
  }
end

Hello all, love this project.

I was hoping if a pull request that implements a feature to colorize strings based on a regular to match will be accepted.

I was hoping something along the lines of:

{name: "Bob Jones", age: 19}.to_json.colorize(:color => :light_blue, :matches => /(?<=)name:\s"[^"]*"/) # Highlights all the name properties 

This is going to be extremely helpful for logging out JSONs and other streams of data making it easier to identify particular lines dynamically.

I am willing to work on this pull request.

In ANSI/Bash, not wrapping color escapes with \[ \] causes line wrap issues due to the prompter not calculating the line length correctly. In readline, while \[ \] doesn't work, \001 and \002 work.

See this StackOverflow answer for an explanation of the issue.