Update. I tried the `file -u` example you gave above and the `-u` flag doesn't exist in my version of `file`. I also find it a bit hilarious that the example lists `ed` as the editor of choice.
Re:You Don't Need a GUI
by a1369209993 on Saturday April 10, 2021 @03:57PM
(#26764557)
> the `-u` flag doesn't exist in [any] version of `file`
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.
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 :-)