How about:
$ file --help | grep util
-u, --utils output utilities related to FILE
$ file -u index.html
index.html: HTML document, ASCII text, with very long lines
cat index.html
ed index.html
lynx index.htmlHow about:
$ file --help | grep util
-u, --utils output utilities related to FILE
$ file -u index.html
index.html: HTML document, ASCII text, with very long lines
cat index.html
ed index.html
lynx index.htmlindex.html <tab>
And you’d get open, copy, rename, create symlink, delete, compress, etc.
Why does the order of commands or their names have any influence on whether pipes can be used? How do you pipe the output of cp into awk?
I can try... Specifically, given a command that produces a list of "everything that can be done with the file", how do I cause the (unstructured) text of that list to be piped into a arbitrary other program, in the same way that `grep foo a.txt | bar` causes a list of occurences of 'foo' in a.txt to be piped into arbitrary program bar.
> How do you pipe the output of cp into awk?
$ cp -vT foo/ bar/* | awk '...'As I understood the suggestion re. file actions it is meant as some sort of interactive completion. So if I type the name of an image file and press tap, I am given the suggestions or options about resizing, format conversion etc. Several shells already have interactive completion of file names.
And I think that pattern makes sense from an exploration perspective. If you learn that file name + tab gives suggestions, then a lot of the learning about what the command line can do can be done directly in the command line.
And maybe it could be a command rather than a tab-press. Then it, given a file, prints typical actions/commands/tasks to stdout and then subsequent CLI tools can be used to process that output.
I really don’t see how this is incompatible with existing workflows :-)
Yeah, I was giving a example of a sensible way to design it, not documenting something that already exists; sorry if that wasn't clear.
> And maybe it could be a command [like `file -u FILE`] rather than a tab-press. Then it, given a file, prints typical actions/commands/tasks to stdout and then subsequent CLI tools can be used to process that output.
Pretty much that, yes.
> I also find it a bit hilarious that the example lists `ed` as the editor of choice.
I don't think unix had TECO as a standard utility, so I went with what was available.
index.html open | sed