6 ms·

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 m

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.

GauntletWizard 5y ago
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.
strictfp 5y ago
Pretty much every linux tool pulls these shenanigans. I hate it when there's no flag to control output.
lytedev 5y ago
What about things like ANSI color codes?
- MereInterest 5y ago
  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 https://superuser.com/a/380778
  - kbrazil 5y ago
    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.
    - laumars 5y ago
      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.
- foodstances 5y ago
  Hope it supports NO_COLOR (http://no-color.org/ http://no-color.org/) env NO_COLOR=1 ...
  - kbrazil 5y ago
    I hadn’t seen this before - thanks for sharing!
- b3morales 5y ago
  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.
  - b3morales 5y ago
    Oh, and I still want `--color=always` or equivalent for when I'm piping into a pager.

GauntletWizard 5y ago

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.

strictfp 5y ago

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

lytedev 5y ago

What about things like ANSI color codes?

MereInterest 5y ago
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 https://superuser.com/a/380778
- kbrazil 5y ago
  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.
  - laumars 5y ago
    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.
foodstances 5y ago
Hope it supports NO_COLOR (http://no-color.org/ http://no-color.org/) env NO_COLOR=1 ...
- kbrazil 5y ago
  I hadn’t seen this before - thanks for sharing!
b3morales 5y ago
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.
- b3morales 5y ago
  Oh, and I still want `--color=always` or equivalent for when I'm piping into a pager.