labath added a comment. If it comes down to choosing between colored output going to stderr and plain output going where it should, i'd go with the second option.
The way I'd implement this to support both things is approximately this: - add color (`has_colors`, `changeColor` and friends) support to `Stream` class, same as `llvm::raw_ostream`. Apart from solving this problem, this will make the two classes more similar, making eventual llvm transition smoother. - the `raw_ostream` shim in the `Stream` class can just forward the relevant operations - make the colored-ness of StringStream configurable at construction time. When constructing the StringStream holding the command output, we would look at whether the final output supports colors (Raphael, would that be `Debugger.getUseColor()?`) or not, and initialize it appropriately. - as an alternative to previous step, it might be good to check how can look a It may be more work than you're ready to put into this right now, but it would be very cool nonetheless, as it would unlock colored output for all other commands (and I can think of a couple who could use that). The downside here is that this would require duplicating the ansi escape sequence code in raw_fd_ostream. However, I believe we already have a code for handling those, so that can hopefully be reused. https://reviews.llvm.org/D54072 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
