Just from the perspective of mapping sentence meanings to bash commands, that's a difficult thing to do. But going beyond that, I think there are issues having to do with the ambiguity of language that just aren't solvable, period.
Take your example: "Show me all my files, including my hidden ones". That, to me, should show all the files on the entire system where I am the owner. Even as someone who ostensibly knows some bash, you missed that you dropped some pieces of data which are relevant in bash terms. "my" indicates ownership, and nowhere in your sentence did you say to limit the function to the current directory. If you're making that mistake as an experienced user, what hope does a beginner have?
`ls -a` actually encodes a fairly complex query, which only becomes apparent when you attempt to really nail down what it does in a natural language. To produce `ls -a`, you would really have to type something like "List the names of all the files, folders, and symbolic links in the current directory that are visible to the current user." You could, of course, start making assumptions about certain parts of this, similar to how `ls` does, but then you get into users guessing which part of the sentences they can elide (why wouldn't we assume that "List the names of the files, folders, and symbolic links in the current directory" wouldn't show us all the files, folders, and symbolic links?). At that point, the user must learn the idiosyncrasies of which exact sentence they have to type in to get what they want: i.e. when they have to say "all", when saying "my" matters instead of saying "the", etc. At that point the natural language stuff is no longer a learning tool, it's a separate, very complicated thing for the student to learn in addition to what they are trying to learn.
As another example of this: if you're willing to accept some ambiguity, why did you choose `ls -a` instead of `find .`? Recognizing that `ls -a` and `find .` do very different things.
To summarize: I don't think it's a bad idea, just an impossible one. :)
I think there are issues having to do with the ambiguity of language that just aren't solvable, period.
This, absolutely. Once you've used a programming language enough, you'll find that natural languages are disturbingly ambiguous; it only works (most of the time, at least) for communicating with other humans because of implied context.
To me and a lot of people, the commandline is already natural language.
`ls -a` is just a contraction for "list all"
Your nine words aren't any more expressive than my two, and that's the problem. There's not much value in being able to express simple commands with long sentences (with often many interpretable meanings)
There _could be_ value in natural language processing for some very complicated commands, but it would have to be fairly intelligent before it would be useful.
A good NLP interface for files would look as different from a command-line as it would from a graphical file manager. You'd want something context-sensitive, with the ability to use pronouns and iterative refinement, some of which would take the place of simple scripting. You'd need to replace many commands with phrases, and many variations on phrases.
Whether you'd get any users is another question.
You might also consider what a command-line interface based on Dasher would look like. Probably not just a simple typing interface. You could extract a great deal of useful information from completion mechanisms, for instance.
> What do people think about wrapping a Natural Language Processing interface around the command line (for educational purposes)?
Fragile, verbose, and actively hostile to learning why anyone would actually use a command line shell to begin with. For example, how would your syntax support redirection?
Bourne shell syntax is hairy enough as it is. The quoting rules are rebarbative and dealing with whitespace can drive you to madness in some circumstances. Adding another thick layer of syntactic sugar onto that is only going to end in tears.
Take your example: "Show me all my files, including my hidden ones". That, to me, should show all the files on the entire system where I am the owner. Even as someone who ostensibly knows some bash, you missed that you dropped some pieces of data which are relevant in bash terms. "my" indicates ownership, and nowhere in your sentence did you say to limit the function to the current directory. If you're making that mistake as an experienced user, what hope does a beginner have?
`ls -a` actually encodes a fairly complex query, which only becomes apparent when you attempt to really nail down what it does in a natural language. To produce `ls -a`, you would really have to type something like "List the names of all the files, folders, and symbolic links in the current directory that are visible to the current user." You could, of course, start making assumptions about certain parts of this, similar to how `ls` does, but then you get into users guessing which part of the sentences they can elide (why wouldn't we assume that "List the names of the files, folders, and symbolic links in the current directory" wouldn't show us all the files, folders, and symbolic links?). At that point, the user must learn the idiosyncrasies of which exact sentence they have to type in to get what they want: i.e. when they have to say "all", when saying "my" matters instead of saying "the", etc. At that point the natural language stuff is no longer a learning tool, it's a separate, very complicated thing for the student to learn in addition to what they are trying to learn.
As another example of this: if you're willing to accept some ambiguity, why did you choose `ls -a` instead of `find .`? Recognizing that `ls -a` and `find .` do very different things.
To summarize: I don't think it's a bad idea, just an impossible one. :)