3 ms·

Yup! In fact, there's only one good reason to do automatic pipe detection, and that's if your tool normally outputs ANSI escape codes, which aren't something yo

Yup! In fact, there's only one good reason to do automatic pipe detection, and that's if your tool normally outputs ANSI escape codes, which aren't something you want in something going to a pipeline.

vidarh 5y ago
Except when you want it. E.g of feeding the output to a pager, or grepping something out and then sending it to the terminal. I hate when tools make this assumption and changes things behind my back.
- talideon 5y ago
  I said _one_ good reason. If a tool did that, I might be a bit annoyed, but I'd at least understand _why_: I'd be less surprised if the colours and formatting disappeared, but tools like awk, cut, sed, &c., behaved. Ideally, I'd just prefer is libxo was common outside of FreeBSD, and I didn't have to worry about massaging stuff into structured data.
burntsushi 5y ago
Do you advocate for ls to change its behavior? Given that it changes its output format based on pipe detection in ways that involve more than just ANSI escape codes. Perhaps this is something that is actually not a "fact," and is something more like an "opinion."
- talideon 5y ago
  TL;DR: principal of least surprise. Bringing `ls` into this isn't a great idea. Advocate? No. Would I excuse it? Yes. When I write tools, I write two kinds: ones that care intended to be consumed by something and ones that are not. If something is even marginally the former, I assume the former. I can excuse a tool having output changing behaviour if it's the latter, and only in the case of dropping ANSI escape codes, but only because it makes sense to pipe such output into, say `pbcopy` and `tee`, without the escape codes for capture. Automagically removing ANSI escape codes is the _most_ I'd be comfortable with, and only because is _reduces surprise_. Something sent to stdout should be the same as something sent to a pipeline, but I can forgive somebody adding ANSI codes to make things clearer to a human reader, for whom those are invisible in the stream. Would I advocate for `ls` not to send ANSI escape codes to a pipeline? Yes. Do I think it's a good idea to pipe from `ls`? Most certainly not! `ls` is written with assumptions about the consuming terminal that defeat the principal of lease surprise.
  - burntsushi 5y ago
    So... if you're okay with how ls changes its output format based on automatic pipe detection, then it seems like there is perhaps more than "one" good reason to do automatic pipe detection. :-) Which is eminently reasonable. But your hard-line stance expressed above is less so. > Bringing `ls` into this isn't a great idea. I perceived your hardline stance as unreasonable personally, and so I wondered where the format changing functionality that most 'ls' implementations perform based on pipe detection fit in your worldview. It seems to me like your hard-line stance is not actually so hard-line. But you do a lot of mental gymnastics to get there, and you end up asserting that 'ls' shouldn't be used in pipelines. Which seems kinda nuts to me to be honest. The better answer here IMO is that one should use "good judgment" when it comes to changing things based on automatic pipe detection. It's a matter of taste and there are more use cases for it than simply removing ANSI codes.
    - talideon 5y ago
      I don't see what's hardline about it: my line is just the principle of least surprise. And to be as emphatic as possible about it, I'm talking about tools that are meant to be consumed by pipelines. > I perceived your hardline stance as unreasonable personally, and so I wondered where the format changing functionality that most 'ls' implementations perform based on pipe detection fit in your worldview. Because the output of `ls` is a trashfire for parsing already. I'd strongly discourage _anyone_ from attempting to parse its output. > But you do a lot of mental gymnastics to get there, and you end up asserting that 'ls' shouldn't be used in pipelines. Which seems kinda nuts to me to be honest. No, I've just had to fix a bunch of broken-ass shell scripts in the past because people didn't realise that the output of `ls` doesn't obey the principle of least surprise. No mental gymnastics here, just a lot of experience fixing other people's problems. About the only good thing that ever comes out of these is that is gives me a way to show people what they can do with safer, more predictable tools, like `find`.
      - burntsushi 5y ago
        "there's only one good reason to do automatic pipe detection" and "please try to adhere to the principle of least surprise" are two different statements. The first is making precise numeric claim about the number of good reasons to do something, while the latter is clearly about espousing a principle. Principles are to be balanced. I'd encourage you to pop up a level here and look at your original comment that sparked this thread: > Yup! In fact, there's only one good reason to do automatic pipe detection, and that's if your tool normally outputs ANSI escape codes, which aren't something you want in something going to a pipeline. There's no nuance there. No balancing of principles. No discussion about "least surprise." Just an opinion masquerading as a fact, and one that I happened to disagree with absent any other context. Your replies since then seem to think you presented a more nuanced case than what you actually did. You've clarified a bit since then, but really haven't acknowledged that your original claim appears to be quite a bit stronger than where you've settled after a few comments into this thread. > No, I've just had to fix a bunch of broken-ass shell scripts in the past because people didn't realise that the output of `ls` doesn't obey the principle of least surprise. No mental gymnastics here, just a lot of experience fixing other people's problems. About the only good thing that ever comes out of these is that is gives me a way to show people what they can do with safer, more predictable tools, like `find`. So now we've moved on from discussing when and where tools should do automatic pipe detection to best practices for shell scripting. Yes, of course, I wouldn't try to parse the output of `ls` in a shell script. But that doesn't mean I'm not going to use `ls` in pipelines ever. Shell scripts are just a subset of what shell is used for. I also use it interactively. In such cases, `ls | grep foo` is a pretty common thing for me to do to see what's in the current directory. Never had a problem with it. But if I were to follow your advice, you'd want me to do what, do something like `find ./ -maxdepth 1 -name 'foo'? (Although, that includes hidden files.) That's a lot less convenient.

vidarh 5y ago

Except when you want it. E.g of feeding the output to a pager, or grepping something out and then sending it to the terminal. I hate when tools make this assumption and changes things behind my back.

talideon 5y ago
I said _one_ good reason. If a tool did that, I might be a bit annoyed, but I'd at least understand _why_: I'd be less surprised if the colours and formatting disappeared, but tools like awk, cut, sed, &c., behaved. Ideally, I'd just prefer is libxo was common outside of FreeBSD, and I didn't have to worry about massaging stuff into structured data.

burntsushi 5y ago

Do you advocate for ls to change its behavior? Given that it changes its output format based on pipe detection in ways that involve more than just ANSI escape codes. Perhaps this is something that is actually not a "fact," and is something more like an "opinion."

talideon 5y ago
TL;DR: principal of least surprise. Bringing `ls` into this isn't a great idea. Advocate? No. Would I excuse it? Yes. When I write tools, I write two kinds: ones that care intended to be consumed by something and ones that are not. If something is even marginally the former, I assume the former. I can excuse a tool having output changing behaviour if it's the latter, and only in the case of dropping ANSI escape codes, but only because it makes sense to pipe such output into, say `pbcopy` and `tee`, without the escape codes for capture. Automagically removing ANSI escape codes is the _most_ I'd be comfortable with, and only because is _reduces surprise_. Something sent to stdout should be the same as something sent to a pipeline, but I can forgive somebody adding ANSI codes to make things clearer to a human reader, for whom those are invisible in the stream. Would I advocate for `ls` not to send ANSI escape codes to a pipeline? Yes. Do I think it's a good idea to pipe from `ls`? Most certainly not! `ls` is written with assumptions about the consuming terminal that defeat the principal of lease surprise.
- burntsushi 5y ago
  So... if you're okay with how ls changes its output format based on automatic pipe detection, then it seems like there is perhaps more than "one" good reason to do automatic pipe detection. :-) Which is eminently reasonable. But your hard-line stance expressed above is less so. > Bringing `ls` into this isn't a great idea. I perceived your hardline stance as unreasonable personally, and so I wondered where the format changing functionality that most 'ls' implementations perform based on pipe detection fit in your worldview. It seems to me like your hard-line stance is not actually so hard-line. But you do a lot of mental gymnastics to get there, and you end up asserting that 'ls' shouldn't be used in pipelines. Which seems kinda nuts to me to be honest. The better answer here IMO is that one should use "good judgment" when it comes to changing things based on automatic pipe detection. It's a matter of taste and there are more use cases for it than simply removing ANSI codes.
  - talideon 5y ago
    I don't see what's hardline about it: my line is just the principle of least surprise. And to be as emphatic as possible about it, I'm talking about tools that are meant to be consumed by pipelines. > I perceived your hardline stance as unreasonable personally, and so I wondered where the format changing functionality that most 'ls' implementations perform based on pipe detection fit in your worldview. Because the output of `ls` is a trashfire for parsing already. I'd strongly discourage _anyone_ from attempting to parse its output. > But you do a lot of mental gymnastics to get there, and you end up asserting that 'ls' shouldn't be used in pipelines. Which seems kinda nuts to me to be honest. No, I've just had to fix a bunch of broken-ass shell scripts in the past because people didn't realise that the output of `ls` doesn't obey the principle of least surprise. No mental gymnastics here, just a lot of experience fixing other people's problems. About the only good thing that ever comes out of these is that is gives me a way to show people what they can do with safer, more predictable tools, like `find`.
    - burntsushi 5y ago
      "there's only one good reason to do automatic pipe detection" and "please try to adhere to the principle of least surprise" are two different statements. The first is making precise numeric claim about the number of good reasons to do something, while the latter is clearly about espousing a principle. Principles are to be balanced. I'd encourage you to pop up a level here and look at your original comment that sparked this thread: > Yup! In fact, there's only one good reason to do automatic pipe detection, and that's if your tool normally outputs ANSI escape codes, which aren't something you want in something going to a pipeline. There's no nuance there. No balancing of principles. No discussion about "least surprise." Just an opinion masquerading as a fact, and one that I happened to disagree with absent any other context. Your replies since then seem to think you presented a more nuanced case than what you actually did. You've clarified a bit since then, but really haven't acknowledged that your original claim appears to be quite a bit stronger than where you've settled after a few comments into this thread. > No, I've just had to fix a bunch of broken-ass shell scripts in the past because people didn't realise that the output of `ls` doesn't obey the principle of least surprise. No mental gymnastics here, just a lot of experience fixing other people's problems. About the only good thing that ever comes out of these is that is gives me a way to show people what they can do with safer, more predictable tools, like `find`. So now we've moved on from discussing when and where tools should do automatic pipe detection to best practices for shell scripting. Yes, of course, I wouldn't try to parse the output of `ls` in a shell script. But that doesn't mean I'm not going to use `ls` in pipelines ever. Shell scripts are just a subset of what shell is used for. I also use it interactively. In such cases, `ls | grep foo` is a pretty common thing for me to do to see what's in the current directory. Never had a problem with it. But if I were to follow your advice, you'd want me to do what, do something like `find ./ -maxdepth 1 -name 'foo'? (Although, that includes hidden files.) That's a lot less convenient.