colored input

[Emilv2]

ack doesn't seem to work very well with colored input, is this simply not supported or could these be considered bugs?

printf "'\033[0;31mNow there is color, now there is not\n" | ack --color color

The red color doesn't go on after color. while in the original string it does not.

printf "'\033[0;31mThe \033[0;32munderline \033[031;mshould be there, but it's over here.\n" | ack --underline there

The underline should be under there but due to the color codes it ends under here.

[petdance]

Yes, ack doesn't work with colored input the way you are expecting.

In your first example, ack turns off the coloring because it's done highlighting the word "color". It doesn't know that the original string had color codes in it.

In the second example, ack doesn't know that some of the characters don't print, so the calculations to figure where the underline should go get messed up.

This is not a bug.

[Emilv2]

Yes I see what is happening, my question was more like why is this not done? Compability with grep?

[petdance]

It's never been something I've ever thought about it before. I've never heard of anyone wanting to search text files that have ANSI color codes in them and have those color codes respected.

[hftf]

I don't have text files containing color codes, but in maybe a handful of complex use cases per year, I've wanted to search the output of a command or script and preserve meaningful color codes (for lightweight syntax highlighting – including meaningful bold and underline elements contained in most of my documents, for example – but more often just the result of another ack or grep search). That would be nice to see when searching.

[n1vux]

wanting to search text files that have ANSI color codes in them

as long as we position Ack as a source-code search-tool and not a general-purpose/natural-language-text search-tool, ANSI color-codes are reasonably considered out-of-scope.

Yes, we all do make use of Ack to filter our program input- and output-data as well as program code (i even use it for natural-language corpus search) but that is off-label use; we should be pleasantly surprised how well it works in off-label usage on data.

(This explicates one of the barriers to making Ack (or an Ack-fork) into a proper natural-language tool -- it would be expected that we could parse non-NL tokens out of the stream (ANSI-color and Unicode and HTML/XML markup etc). And then would need flags to indicate which filtering to use on STDIN. Since we do NOT parse the HTML even when --html is in effect, this would be a major scope change. If one wants XML/HTML parsing in a Grep, see xml_grep . Suddenly i grok Andy's reticence to add NL-leaning features.)