"Start with supporting stdin/stdout as the only input and output. This ensures that it is composable with other utilities. You may find you never need anything else"
Need to read a file? `my-cli < file`
Need to write a file? `my-cli > file`
How about read from a URL? `curl url | my-cli`
vim <(curl -fsL https://news.ycombinator.com)
Read standard input in a shell script:
#!/usr/bin/env bash
cat <&0 > $(date +%s).txtOtherwise it still might be useful, but in general it's kind of unnecessary. It adds logic to your application that it doesn't need, which violates "do one thing, and one thing very well" (albeit only a very small violation).
Sure. However, for example, GNU sort doesn't work that way. Most utilities don't work that way. Most utilities accept a file as an source of input, and most of those don't act on the inode. That's the status quo.
sort < bigfile > bigfile
$ sort "$name" | sponge "$name"
$ sort -o "$name" "$name"
I'm wondering if there's any practical use for the behaviour, or if it's worth hacking a shell such that it produces a warning/interactive confirm prompt for it (or transparently buffers to DWIM maybe?)
Picking one input to still be consumed from stdin can make sense, though. A special case of this is config files, which are almost never read from stdin (they usually have a default location or several).
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?
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.
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.
I think `foo /path/to/myfile` is what the parent was trying to say.
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.
This is highly useful if you want to allow composition into scripts without forcing users to dynamically build parameters. Meaning, they can use, e.g. `FILE_NAME=${FILE_NAME:-"-"}; some-util --output $FILE_NAME;` and not have to decide whether or not to use the --output parameter in their script.
I know that it could be done with a loop, but that's a little unwieldy compared to `ls | xargs my-cli`
lol, this is really turning the whole 'useless use of cat' thing on its head.
The problem with that example is parsing `ls` output.
`cat -- *` might be the right choice. Maybe `find . -maxdepth 1 -type f -exec cat -- {} +`
Yeah, I left that alone to keep things simpler and was assuming `ls` was simply being used as short-hand for "some unspecified approach to outputting file names". In a context where hard-to-handle filenames are possible, you'd of course need to do something a little more robust.