I think, this is a superb, excellent, necessary [etc...] idea.
Also, this can be a HUGE project. I am thinking of the interfaces, to
make that program scalable. A (simple) database will be necessary, that
contains parameters, flags and comments. In the beginning a XML database
perhaps is overkill, but in the long run it should be ok.
When I hit the <TAB> button twice, I got 2354 possibilities.
So, how could we have the chance to feed the database in a complete way?
I ask myself, how to obtain this information automatically. Could this
be extracted from man-pages or the texinfo/ info-files?
I don't know the nroff or info-format very well. But I saw, that command
options appear after an ".IP " nroff-command in the man-pages?
If I knew that, I could write a parser for it.
The good thing about the extraction strategy is, that there is still a
quite complete information source to use. But I don't know the level of
standardization of man-pages.
I also think, that there should be an interface to build different types
of GUIs. For example, it could be readline, Curses::Widgets, Gtk or
QT-based (or what toolkit the user wants). So I think we should build
generic programs, that can appear according to that parameter database.
The only information that they need, is already written command line, to
Let's brainstorm more all around the globe :)
BTW.: How do we call the project?
"SCCL" = SoftCore Command Line ? :)
On Mon, Oct 14, 2002 at 12:37:22PM +0530, Sriram Karra wrote:
Suraj Kumar <suraj@xxxxxxxxxxx> writes:
Natarajan wrote on Sat, Oct 12, 2002 at 08:07:13PM +0530:
nat> Command line interface (CLI) and Graphical user interface(GUI)
nat> are widely used and each have their own advantages (mutually
nat> exclusive) and patrons. But in CLI, we tend to forget the
nat> parameters for many of the commands. One of the famous examples
nat> is the FIND command. It has too many options and too many
nat> features, that you forget the commands quickly. In order to
nat> find a solution to this problem, Karra proposes a new software
nat> that will pop-up a window, and will have all the options
nat> available to us in a GUI form.
If its about having a customisable command line completion,
bash_completion (source /etc/bash_completion) on Bash2 does the job.
It is not really about "completion" in any sense. Basically, my point
is this: There is something lacking in a command line interface.
A cli enhances productivity when the user knows exactly what command
to use and the exact syntax of the command. But consider what happens
when you do not know anything about the command. Me feels that
pouring over man pages is a terrible waste of time. Here is where a
GUI rules. BUt using a gui repeatedly is a bloody Pita.
So, can we come up with a mechanism whereby we have a gui that will
help us become better *cli* users ??
The answer is yes. When my idea is fully implemented, you will have
1. You are at the shell and you are about to type a command.
2. You get stuck somewhere because you do not know what is the name of
the flag that accomplishes your task.
3. So, you type some magic sequence that will bring on a gui version
for this command.
4. You will click some buttons, choose a radio button or whatever
based on information present there. Then you will press "exit".
5. The software will now generate the right CLI and put it at your
cursor, which you can then execute.
What the program has done for you is this: it has taught you the cli
command you were searching for. And now that you know the cli flag
for your task, you can skip the gui invocation from next time. There!
we have just used the gui to help us become better cli users.
Now is this a better approach than pouring over tonnes of man pages?
I say yes!
there are a good stock of bash functions in place already to do stuff
like completing the host names while sshing, etc., Since these are
functions all that we need to do is to write a function that will pop
up some window and then return the strings for insertion into the
I took a quick look at Kaptain. It works *exactly* as I had
anticipated. The only part that needs to be done is integrate it with
bash and like shells. And this should not really be very difficult.
Well, all's well that ends.
To unsubscribe, email ilugc-request@xxxxxxxxxxxxxxxxxx with
"unsubscribe <password> address"
in the subject or body of the message.