4 ms·

Outputting to stdout gives the control and power to the user - if they want it in a file which they want to name, they can do that; if they want to pass the out

by Annatar 10y ago

Outputting to stdout gives the control and power to the user - if they want it in a file which they want to name, they can do that; if they want to pass the output as input to another application - they can do that too. There are few usage scenarios where such behavior isn't enough, like for example fsck, but even there this paradigm is flexible enough to work - for such applications could be split into an analyzer and a repair program. There is nothing stopping one from outputting a binary data stream on stdout; Lots of applications do exactly that on UNIX, compressors come to mind. What use case have you where stdout/stdin/stderr isn't enough on an operating system family where the core paradigm of usage is that everything is a binary stream of data?

jpitz 10y ago
> Outputting to stdout gives the control and power to the user - if they want it in a file which they want to name, they can do that; if they want to pass the output as input to another application - they can do that too. Please note that we already agree here. > What use case have you where stdout/stdin/stderr isn't enough on an operating system family where the core paradigm of usage is that everything is a binary stream of data? My argument isn't that I have a use case where it 'isn't enough.' My argument is that many people come to a cli utility expecting that <foo /path/to/myfile> simply works.
- Annatar 10y ago
  My argument is that many people come to a cli utility expecting that <foo /path/to/myfile> simply works. So are for or against that? If you're for the < /path/to/my/file argument, then we are in complete agreement. A command line application should read from stdin where that applies.
  - dllthomas 10y ago
    It seems to me there was confusion here caused by an unfortunate choice of angle brackets for quoting. I think `foo /path/to/myfile` is what the parent was trying to say.
    - jpitz 10y ago
      It was. Thank you. I want stdin to work. I also want specifying a file name to work. I think supporting both is good UI design, and follows the principle of least surprise.

by Annatar 10y ago

jpitz 10y ago

> Outputting to stdout gives the control and power to the user - if they want it in a file which they want to name, they can do that; if they want to pass the output as input to another application - they can do that too. Please note that we already agree here. > What use case have you where stdout/stdin/stderr isn't enough on an operating system family where the core paradigm of usage is that everything is a binary stream of data? My argument isn't that I have a use case where it 'isn't enough.' My argument is that many people come to a cli utility expecting that <foo /path/to/myfile> simply works.

Annatar 10y ago
My argument is that many people come to a cli utility expecting that <foo /path/to/myfile> simply works. So are for or against that? If you're for the < /path/to/my/file argument, then we are in complete agreement. A command line application should read from stdin where that applies.
- dllthomas 10y ago
  It seems to me there was confusion here caused by an unfortunate choice of angle brackets for quoting. I think `foo /path/to/myfile` is what the parent was trying to say.
  - jpitz 10y ago
    It was. Thank you. I want stdin to work. I also want specifying a file name to work. I think supporting both is good UI design, and follows the principle of least surprise.