It does the sane thing when it detects the output is being pipped and doesn't output the color controls.

grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not.

exa's opinion is this: users shouldn't be expected to know that adding colour to ANSI terminal output adds more bytes to the stream. If you run `foo`, see that it outputs a line, then run `foo | grep line`, you'd expect to see that line without having to stop and think about what representation the colours had.

Yeah, it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes. There's just no way for exa to know that it's being piped into less while keeping the above rule true too.

> it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes.

I'm not certain if it's exactly what you're getting at, but less can be instructed to parse ANSI color sequences, and output them, with the -R flag. (If you forget to put -R on the command line, or some utility automatically starts less for you, you can also type "-R" while in less to trigger that behavior.) That said, less has to be fed the sequences, and most programs will not output color sequences when piped to less, as they detect that the output isn't a TTY (this is normally the right thing to do, it just kinda sucks in less's case) so you might need to, e.g., that_prog --color=always | less.

> There's just no way for exa to know that it's being piped into less while keeping the above rule true too.

Yeah, this is the real problem. I kind of wish there was some sort of content negotiation between piped utilities, s.t. less could inform the upstream utility of "hey! I speak ANSI color codes!".

What follows is definitely well into the "WTF too clever" column and I do not recommend it, but, this is HN: I presume you could riff through /proc trying to find the other end of the pipe that you're writing to (I think /proc on Linux has that) and then, if the executable's name is "less", well, you see where I'm going…

That's where you need something like PowerShell, which pipes objects around instead of streams of bytes which are probably text.

Of course, PowerShell has its own issues, but the idea of a shell with more meaning attached to things is appealing. Rebuilding an ecosystem that can handle it all though... not so plausible!

>> grep doesn't have the --colour option ternary for nothing.

> grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not.

Didn't I say that? Ternary. On, off, detect.

Oh, I completely missed that word. My bad.

I don't know if exa does this, but most command line tools disable colorized output automatically if they determine that stdout is not an interactive terminal.