Use with stringstreams about termcolor

[ikalnytskyi]

@gelldur well, I come up with a solution. will implement it pretty soon.

[ikalnytskyi]

@stonier Hm.. Originally the idea was is to be protected from Unix pipes. For instance, if you run program that way -

$ ./my_program > out.txt

stdout is not a tty, and ASCII characters won't get to output file (which is desired behaviour in most case).

However, I think we need to think how to avoid it and fix with std::stringstream.

[ikalnytskyi]

Well I think we can do the following things:

• if stream is either stdout or stderr and is not atty -> strip ASCII escape sequences
• otherwise - use them

In that case the case with redirection of standard io streams and having buffered string stream will be covered. However, I'm not very happy with such non obvious complexity. Need to think a bit more.

[stonier]

Aha, I see.

Your logic sounds fine.

Though I do agree, with a stringstream you start moving into the realm of letting the user get himself into trouble (or not) and you cannot provide the protection there as he may eventually pipe that string out as you illustrated above.

Perhaps a better alternative is equipping the user with a tool that they can use to strip output from a termcolor enabled program? e.g.

$ ./my_program | strip_termcolor_sequences > out.txt

[ikalnytskyi]

@stonier We can't be sure such a tool will be widely distributed. I start thinking about explicit manipulator, like:

std::cout << termcolor::force << termcolor::red << "RED message" << termcolor::reset << std::endl;

Or maybe it's better to make force mode by default, and use tty mode to strip colors if output isn't tied with tty:

std::cout << termcolor::tty << termcolor::red << "RED message" << termcolor::reset << std::endl;

Anyway, thank you very much for raising an important concern! I'll try to come up with solution.

[stonier]

The manipulator approach is interesting.

I would offer one perspective. For a user of a program that utilises this library, there are many ways of stripping colour codes if you wish (google for 'bash strip terminal color sequences'), but there is no way of re-inserting colour codes if the library/programmer has decided to strip them for you.

A good example is cmake output getting redisplayed in jenkins. If cmake had decided to strip sequences for logging, there would be no way I could utilise the AnsiColor Plugin to get the colours re-discovered in a jenkins log view.

[davidvanlaatum]

should at least fix the crash for now ;) even if its just assume its not a tty. Just need to handle get_standard_stream returning NULL. as for determining if a stream is a tty I suggest some ability to provide a user function to determine if it is

[ikalnytskyi]

@davidvanlaatum wow! nobody told be that there's a crash! it definitely needs to be fixed.

[davidvanlaatum]

yep fileno(NULL) goes boom at least on osx

[ikalnytskyi]

I'll prepare a fix and add test to CI for that case. Thanks a lot!

as for determining if a stream is a tty I suggest some ability to provide a user function to determine if it is

I agree on this. I'll add it very soon.

[ikalnytskyi]

Fixed segmentation fault in 519358f.

[gelldur]

Any updates on this :) ?

[ikalnytskyi]

@gelldur unfortunately didn't come up with a good solution. :( I'll think about it.

[gelldur]

Nice thx! Updating fork :)