3 ms·
Ah, thanks for the clarification, it definitely cleared up what you mean. As I understood the suggestion re. file actions it is meant as some sort of interacti
by henrikeh 6y ago
Ah, thanks for the clarification, it definitely cleared up what you mean.
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 :-)
- henrikeh 6y agoUpdate. 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.
- a1369209993 6y ago> 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.