3 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 o
by 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 agoMy 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 agoIt 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 agoIt 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.