News for hackers. Stuff that matters.
Re:Exploring CLI Best Practices by jpitz on Wednesday October 12, 2016 @10:44AM (#12693287)
> 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.

Re:Exploring CLI Best Practices by Annatar on Wednesday October 12, 2016 @12:34PM (#12694330)
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.

Re:Exploring CLI Best Practices by dllthomas on Wednesday October 12, 2016 @01:38PM (#12694950)
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.

Re:Exploring CLI Best Practices by jpitz on Wednesday October 12, 2016 @02:10PM (#12695212)
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.