Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address FIXME: Add --no-strip-ansi-escapes option #672

Closed
wants to merge 1 commit into from
Closed

Address FIXME: Add --no-strip-ansi-escapes option #672

wants to merge 1 commit into from

Conversation

chisophugis
Copy link

This option allows overriding Ninja's (usually useful) behavior of
stripping ANSI escapes when its output is not a smart terminal (e.g., a
dumb terminal, or redirected to a file).

I ran into a situation where I needed this, and lo and behold there was a FIXME in the source, so I thought I'd give it a shot.

Some things I would specifically like a second opinion on:

  • The way I added the configuration option (is this the "right" way?)
  • The option name
  • The help text

This is a follow-up to #198, and now that I see it replicates the functionality in #435, but in a far simpler way (just enough to address the FIXME). In the future, it would be possible to add a corresponding --strip-ansi-escapes (following the --foo/--no-foo pattern) if it is desirable to be able to force this option on (but in the grand Ninja tradition, I've implemented the simplest thing that addresses the use case).

This option allows overriding Ninja's (usually useful) behavior of
stripping ANSI escapes when its output is not a smart terminal (e.g., a
dumb terminal, or redirected to a file).
@buildhive
Copy link

Evan Martin » ninja #629 SUCCESS
This pull request looks good
(what's this?)

@nico
Copy link
Collaborator

nico commented Oct 18, 2013

Thanks for the patch! There are several issues that deal with ninja's output behavior (#659, #581, #480, #420), I think it might make sense to come up with something that addresses them all (not sure though). I haven't really thought about this though. Might make sense to discuss output behavior on the mailing list.

@chisophugis
Copy link
Author

I definitely think a discussion is a good idea for a "quiet" mode, since there are a couple "axes" along which quietness can be defined. I'll try to get to that.

However, the stripping of ANSI escapes from subprocess output is a very specific isolated operation that Ninja performs, so I'm hesitant to try to integrate it into something more general. Maybe the option should be called --no-strip-subprocess-ansi-escapes (which unfortunately makes the name longer than it already is; suggestions welcome). It's fundamentally about not tampering with subprocess output, rather than somehow modifying "Ninja's output" (except from a broadest holistic "UX" perspective of the phrase "Ninja's output", which is a much more complicated issue that #581, #480, and #420 are touching on).

The issue of overriding #659 seems to be primarily about how Ninja decides whether it is outputting to a terminal or not. As I mentioned, this patch is not about deciding whether output is to a terminal, it is about deciding whether to modify subprocess output before printing it. The use case where I ran into this was when running ninja under watch, and so Ninja is not printing to a terminal, and I wouldn't want it to think that it is (e.g. no overprinting); yet Ninja was munging the subprocess output (clang, in this case) so that it showed up with no colors.

To summarize: There are quite a few pending issues related to Ninja's output, but I don't think that that any of them fundamentally change the desirability of adding a commandline option for overriding Ninja's heuristic stripping of ANSI escapes in subprocess output (which is what this patch does).

@evmar
Copy link
Collaborator

evmar commented Oct 18, 2013

To Nico's point, I agree with the goal of being able to override the ANSI stripping; what he was pointing out is that there are cluster of related feature requests in this area and if we added a separate command line option for each the majority of the --help output would be listing them out. :)

@chisophugis
Copy link
Author

So basically the issue is just finding a way to simplify the space of possible ways in which ninja's output can be controlled into a small number of options that satisfy all the demands?

@evmar
Copy link
Collaborator

evmar commented Oct 18, 2013

Yes. For example, perhaps there should be a single --output-format=raw flag (that would force no ANSI stripping) that would accommodate the other needs.

@mgaunard
Copy link

Currently, colors are stripped whenever piping to less, so this also affects issue #413

mgiuffrida added a commit to mgiuffrida/ninja that referenced this pull request Jan 27, 2017
Adds the general-purpose -o flag to address ninja-build#746, with options for
verbosity (ninja-build#480) and control sequence stripping (ninja-build#581, ninja-build#672, ninja-build#916). Also
provides the ability to enable both verbose and raw output as a
workaround for ninja-build#1214 without changing the existing verbose behavior.

-o verbose  show all command lines while building
-o quiet    hide command lines and outputs while building
-o raw      never strip control sequences from output
-o strip    always strip control sequences from output
-o color    strip most control sequences from output, but retain color codes

This patch does not affect Ninja's defaults of normal verbosity and
smart terminal detection for escape sequence stripping.

"-o color" is particularly useful for utilities like `head` and
`less -R` that interpret color codes from stdin and pass this colored
output to stdout. Any valid ANSI color code, of the form:

    `'ESC' '[' [ colors ] 'm'`

where `colors` is a semicolon-delimited list of optional integers:

   `[ n ] [ ';' colors ]`

is retained in its entirety when using "-o color" (any other CSI escape
sequences besides ANSI color codes are still stripped for non-smart
terminals).
mgiuffrida added a commit to mgiuffrida/ninja that referenced this pull request Jan 27, 2017
Adds the general-purpose -o flag to address ninja-build#746, with options for
verbosity (ninja-build#480) and control sequence stripping (ninja-build#581, ninja-build#672, ninja-build#916). Also
provides the ability to enable both verbose and raw output as a
workaround for ninja-build#1214 without changing the existing verbose behavior.

-o verbose  show all command lines while building
-o quiet    hide command lines and outputs while building
-o raw      never strip control sequences from output
-o strip    always strip control sequences from output
-o color    strip most control sequences from output, but retain color codes

This patch does not affect Ninja's defaults of normal verbosity and
smart terminal detection for escape sequence stripping.

"-o color" is particularly useful for utilities like `head` and
`less -R` that interpret color codes from stdin and pass this colored
output to stdout. Any valid ANSI color code, of the form:

    `'ESC' '[' [ colors ] 'm'`

where `colors` is a semicolon-delimited list of optional integers:

   `[ n ] [ ';' colors ]`

is retained in its entirety when using "-o color" (any other CSI escape
sequences besides ANSI color codes are still stripped for non-smart
terminals).
mgiuffrida added a commit to mgiuffrida/ninja that referenced this pull request Jan 27, 2017
Adds the general-purpose -o flag to address ninja-build#746, with options for
verbosity (ninja-build#480) and control sequence stripping (ninja-build#581, ninja-build#672, ninja-build#916). Also
provides the ability to enable both verbose and raw output as a
workaround for ninja-build#1214 without changing the existing verbose behavior.

-o verbose  show all command lines while building
-o quiet    hide command lines and outputs while building
-o raw      never strip control sequences from output
-o strip    always strip control sequences from output
-o color    strip most control sequences from output, but retain color codes

This patch does not affect Ninja's defaults of normal verbosity and
smart terminal detection for escape sequence stripping.

"-o color" is particularly useful for utilities like `head` and
`less -R` that interpret color codes from stdin and pass this colored
output to stdout. Any valid ANSI color code, of the form:

    `'ESC' '[' [ colors ] 'm'`

where `colors` is a semicolon-delimited list of optional integers:

   `[ n ] [ ';' colors ]`

is retained in its entirety when using "-o color" (any other CSI escape
sequences besides ANSI color codes are still stripped for non-smart
terminals).
timniederhausen pushed a commit to timniederhausen/ninja that referenced this pull request Sep 19, 2017
Adds the general-purpose -o flag to address ninja-build#746, with options for
verbosity (ninja-build#480) and control sequence stripping (ninja-build#581, ninja-build#672, ninja-build#916). Also
provides the ability to enable both verbose and raw output as a
workaround for ninja-build#1214 without changing the existing verbose behavior.

-o verbose  show all command lines while building
-o quiet    hide command lines and outputs while building
-o raw      never strip control sequences from output
-o strip    always strip control sequences from output
-o color    strip most control sequences from output, but retain color codes

This patch does not affect Ninja's defaults of normal verbosity and
smart terminal detection for escape sequence stripping.

"-o color" is particularly useful for utilities like `head` and
`less -R` that interpret color codes from stdin and pass this colored
output to stdout. Any valid ANSI color code, of the form:

    `'ESC' '[' [ colors ] 'm'`

where `colors` is a semicolon-delimited list of optional integers:

   `[ n ] [ ';' colors ]`

is retained in its entirety when using "-o color" (any other CSI escape
sequences besides ANSI color codes are still stripped for non-smart
terminals).
@jhasse
Copy link
Collaborator

jhasse commented Nov 13, 2018

I think the solution, which would accommodate all needs, would be something like #1210.

As for the disabling of output stripping, please see #1268 (comment).

@jhasse jhasse closed this Nov 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants