Hacker News Reader

Comment by drivers99 | Hacker News Reader

> I can right-click to see everything that can be done with the file, including some third party programs

Smart move by (for instance) Microsoft when they did that in Windows 95 and continued it til now. You could theoretically design the same functionality into a text user interface. Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with) it could give you a menu to choose from context specific commands. It would seem pretty natural in that case if you are using post-fix (arguments(s) and then commands, like in Forth). Maybe something already exists like that.

View on HN

> Like if you type the name of something (a filename) and hit enter (or maybe tab? space? Whatever the designer comes up with)

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.html

I meant like

index.html <tab>

And you’d get open, copy, rename, create symlink, delete, compress, etc.

That sounds like a GUI; how do I pipe [open, copy, rename, etc] into sed or awk? (Because the^Wa problem with GUIs is that the answer tends to be "Why would you want to do a wierd thing like that?".)

Can you explain more clearly what you mean?

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?

> Can you explain more clearly what you mean?

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 '...'

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 :-)

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.

> 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.

It's just postfix notation. I don't see why you shouldn't be able to do something like:

index.html open | sed

In bash I can type, for example, "git <tab><tab>" and it will list out all of the git commands. Not quite as nice as a menu, I suppose, but still helpful for discoverability.

Reply on news.ycombinator.com