3 ms·

> and in general best practice is (or was) for commands to not alter their behavior based on whether they're attached to a terminal or not. Not so sure about t

> and in general best practice is (or was) for commands to not alter their behavior based on whether they're attached to a terminal or not. Not so sure about that. ls has been changing its output format based on whether it is being used interactively or not for as long as I can remember at least. Both GNU and BSD versions.

simias 6y ago
Technically it's based on whether the output is a tty or piped/redirected into something, not whether it's run from the shell's prompt or a script. So for instance if you run a bare `ls` from a script that outputs straight into the terminal you'll get the multi-column "human readable" output. Conversely if you type `ls | cat` in the shell you'll get the single column output. It can definitely be surprising if you don't know about it but technically it behaves the same in scripts and interactive environments.
- burntsushi 6y ago
  That's exactly what I meant. I used "interactively" to mean "attached to a tty." Look at what I was responding to: "for commands to not alter their behavior based on whether they're attached to a terminal or not" ls is a clear counter-example of that. I think the behavior is a good thing. I'm pushing back against this notion of what is "best practice" or not. It's more nuanced than "doesn't change its output format."
JoshTriplett 6y ago
Fair distinction. There's a kind of unwritten understanding of what programs should and shouldn't do based on isatty, and I've never seen it explicitly documented. Things many programs do if attached to a TTY: add color, add progress bars and similar uses of erase-and-redisplay, add/modify whitespace characters for readability, refuse to print raw binary, etc. Things some programs do, which can be problematic: prompt interactively when they're otherwise non-interactive. Things no program does or should do: change command-line processing, semantic behavior, or similar.
- burntsushi 6y ago
  > Things no program does or should do: change command-line processing, semantic behavior, or similar. Arguably ripgrep breaks this rule. :-) Compare `echo foo | rg foo` and `rg foo`. The former will search stdin. The latter will search the current working directory. In any case, I bring this up, because I've heard from folks that ripgrep changing its output format is "bad practice" and that it should "follow standard Unix conventions and not change the output format." And that's when I bring up `ls`. :-)
  - sylvestre 6y ago
    This is one of the thing that I loved starting using rg :)

simias 6y ago

Technically it's based on whether the output is a tty or piped/redirected into something, not whether it's run from the shell's prompt or a script. So for instance if you run a bare `ls` from a script that outputs straight into the terminal you'll get the multi-column "human readable" output. Conversely if you type `ls | cat` in the shell you'll get the single column output. It can definitely be surprising if you don't know about it but technically it behaves the same in scripts and interactive environments.

burntsushi 6y ago
That's exactly what I meant. I used "interactively" to mean "attached to a tty." Look at what I was responding to: "for commands to not alter their behavior based on whether they're attached to a terminal or not" ls is a clear counter-example of that. I think the behavior is a good thing. I'm pushing back against this notion of what is "best practice" or not. It's more nuanced than "doesn't change its output format."

JoshTriplett 6y ago

Fair distinction. There's a kind of unwritten understanding of what programs should and shouldn't do based on isatty, and I've never seen it explicitly documented. Things many programs do if attached to a TTY: add color, add progress bars and similar uses of erase-and-redisplay, add/modify whitespace characters for readability, refuse to print raw binary, etc. Things some programs do, which can be problematic: prompt interactively when they're otherwise non-interactive. Things no program does or should do: change command-line processing, semantic behavior, or similar.

burntsushi 6y ago
> Things no program does or should do: change command-line processing, semantic behavior, or similar. Arguably ripgrep breaks this rule. :-) Compare `echo foo | rg foo` and `rg foo`. The former will search stdin. The latter will search the current working directory. In any case, I bring this up, because I've heard from folks that ripgrep changing its output format is "bad practice" and that it should "follow standard Unix conventions and not change the output format." And that's when I bring up `ls`. :-)
- sylvestre 6y ago
  This is one of the thing that I loved starting using rg :)