Hacker News Reader

Comment by b3morales | Hacker News Reader

Another DON'T, silently switching between JSON and human-readable depending on whether the output destination is a pipe. Just an extra hassle when I'm writing my downstream command. Or could be phrased as a DO: give the user a switch to pick the output format, if you have both.

View on HN

I started to try to make an argument for pipe autodetection, but I just can't. It seems like a useful feature but is actually a trap. Shell scripts that are going to rely on json output should always explicitly specify that they want json output, and giving them the ability to shortcut that by autodetecting a pipe will only make it easy to ignore that - And then break when some other format comes into vogue. Human readable output should generally be the default, unless the programs are explicitly designed as only part of a pipeline.

Having multiple outputs is a great feature, though. I'm especially fond of tooling in Kubernetes that allows you to nicely pipe things in and out in multiple formats.

Pretty much every linux tool pulls these shenanigans. I hate it when there's no flag to control output.

What about things like ANSI color codes?

My preference would be to leave them in if they're the default, but to have an option to switch entirely to a more machine-readable format. It's a single line of sed to strip them out[0], and it's a bigger pain to figure out why a program has different behavior when debugging.

[0] https://superuser.com/a/380778

I typically run the command output through `cat` to see if it does different things when outputting to the terminal vs piping.

The biggest changes are typically ANSI color codes and column length. Some programs do strange things, like changing how they escape characters (ls).

JC turns off ANSI color codes when it’s output is not a terminal, but that’s it.

Changes in column length isn’t something that can’t be helped. The issue is that when a command outputs to a TTY, you can use that file descriptor to get the width of the TTY (ie your terminal emulator). But if you are piping a command then it’s STDOUT is no longer a TTY and thus you have no idea how wide the terminal is.

Hope it supports NO_COLOR (http://no-color.org/)

    env NO_COLOR=1 ...

I hadn’t seen this before - thanks for sharing!

Good question; those are more reasonable to me since they aren't visible as characters and don't change the structure. So if I'm looking at the colorized output I can still use that as the basis for a sed or awk script operating on the non-colorized version.

Oh, and I still want `--color=always` or equivalent for when I'm piping into a pager.

Reply on news.ycombinator.com