Re: [gtk-list] Re: PROPOSAL: Automatic wrapping of CLIs with GUIs

[nelson-gtk crynwr com]

Tim O'Neil writes:
 > > Would it be possible for the freeware community (pushed by GNOME
 > >developers) to come up with an application level way of allowing this ?
 > >
 > >Kate
 > 
 > If you feel strongly about such a program, I would say write it.
 > Then see if it takes hold. Its the only way, really. You never
 > know, it just might turn out to be The Killer Utility.

Been there, tried that, didn't get very far with it.  My start at a
database of option descriptions is at the end.  Unfortunately, I
started with one of the most optionable programs: ls.  And here's the
gist of the messages explaining the idea, to and from people.  People
were basically dubious, not of the value of it, but of the probability
of my succeeding with it.  ">"-quoted text is written by other people, 
left-margin text is written by myself.

First, the introductary message, followed by the responses, sometimes
with additional explanation by myself.
-russ

----------------------------------------------------------------

I'm wanting to make Unix more usable.  Idea is that programs that run
programs (like a shell, or a GUI) can query the program about how to
run it, and get the information back in a structured format.  Also be
able to ask the program to do string completion.  Obviously you have a
chicken and egg problem, so the shell/GUI can fall back to a database
that describes the program's options.

----------------------------------------------------------------

 > I recall a long discussion about this a few years ago.  I think it was in a
 > GNU group and centered around bash and getopt_long().
 > 
 > The conclusion was that it would require
 >     - a database, which would be constantly out of data, or
 >     - a magic program option, which wouldn't work with existing binaries, or
 >     - a defined structure in the binary much like the existing getopt()
 >     string.
 > 
 > Option #3 had its own problems, but seemed to be the best choice at the
 > time.

----------------------------------------------------------------

 > I don't think I fully comprehend the gist of this.  If you could
 > explain some more what would actually happen I could make a more
 > educated assessment.

The idea is to describe the command-line options of the program in a
structured manner, so that an external program can build up a valid
command line, and can describe the meaning of those options to the
user.  So that, when I'm typing a ``find'' command, I can say -type
<tab>, and get a listing of the valid types and their meanings.

The net result would be that the shell (be it text or gui), would
automagically be a menuing shell.  Hit <tab>, and you see a listing of
all the commands on your path, and a synopsis of what they do.

Essentially, you could write one GUI program to use this information,
and it would transform all Unix programs into graphics programs.

It doesn't matter where this information comes from.  It could come
from a standard --describethyself argument, or it could be encoded in
the binary, or it could come out of a database.

 > We also try to put wmconfig files in packages like lynx so that
 > it gets started with xterm -e.  Top will have one as well.  Obviously
 > this doesn't solve all problems, though

Right.  My plan doesn't require or inhibit X.  But neither does it
deal well with text-mode interactive applications.  All it's designed
to do is be able to build up command lines, but do so in a manner
that's still useful once you know how to do it yourself (but have
forgotten which character to give to find's -type option).

Kind of like a man page that you don't need to run man to get.

----------------------------------------------------------------

 > Ah yes, Twenex-stype argument completion.  This suggestion has come
 > up now and then over the past 20 years, and the conclusion has
 > always been that it's not the solution to any pressing problem.
 > For really naive users, you're better off with a menu shell of some
 > sort.  Once people get a little more sophisticated, there's a lot
 > to be said for the 100% consistent syntax and globbing behavior we
 > have now rather than the capricious expand-sometimes rules of
 > systems like MS-DOS.

Yes, I'm thinking that this would be of most use to the naive user,
because it would act as a menu shell.  But it would also be useful to
the sophisticated user who forgets, for example, what characters are
valid following find's -type option.

It would also transform the problem of building a Unix command from
recollection to recognition, the latter being a much simpler problem.

The idea was mostly prompted by the reaction of a group of
click-n-drool NT sysadmins.  It was a mixture of pity, grudging
respect, and fear, as they watched me issue command after command from
memory.

----------------------------------------------------------------

 > 
 > Let me try the "why re-invent the wheel" answer
 > 
 > Get a copy of Linuxconf and the classes therein. Also talk to Caldera who
 > are sponsoring a related project

Not what I was proposing at all.  My plan was to give a shell access
to information about a program's options.  The idea is that the same
information could be used to create a menuing shell for beginners, or
a completion shell for experts.  Let's say that I'm typing a find
command, and can't recall what the characters are that follow the
-type option.  I just hit <tab>, and get a listing of the options, and
their meanings.

This information about the program would be retrieved by whatever
means necessary, by a combination of a database, parsing the --help
output (for those programs for which the output can be parsed),
modifying the binaries to include the information, or modifying the
programs to generate it when given a --describethyself option.

----------------------------------------------------------------

 > Hi,
 > 
 > I'm not sure whether it can be done.  But it would be great to have it (I
 > very much like the way I can just press "?" anywhere on a Cisco command 
 > line...).

----------------------------------------------------------------

 > Sounds like a good idea to me...I'm not sure how the best way to make
 > it work is, but it sounds like a good idea.  I'm certainly sick of
 > looking up how 'find' works all the time.  :-)

----------------------------------------------------------------

And finally, here's the database format I had consed up.


# string==/value/documentation/
# if a string appears multiple times, it's one of the choices.
# A value may contain another string referenced by $stringname.
# A string may be repeated zero or more times if it is suffixed with *
# every command must define a ``command'' string.

command==/ls $option* $file*/List information about the FILEs (the
current directory by default). Sort entries alphabetically if none of
-cftuSUX nor --sort./

option==/-A --almost-all/do not list implied . and ../
option==/-a --all/do not hide entries starting with ./
option==/-B --ignore-backups/do not list implied entries ending with ~/
option==/-b --escape/print octal escapes for nongraphic characters/
option==/-C/list entries by columns/
option==/-c/sort by change time; with -l: show ctime/
option==/--color$when*/control whether color is used to distinguish file types./
when==/=never/Never use color/
when==/=always/Always use color/
when==/=auto/Use color sometimes/
option==/-D --dired/generate output designed for Emacs' dired mode/
option==/-d --directory/list directory entries instead of contents/
option==/-F --classify/append a character for typing each entry/
option==/-f/do not sort, enable -aU, disable -lst/
option==/--format=$format/Listing format/
format==/across/same thing as -x/
format==/commas/same thing as -m/
format==/horizontal/same thing as -x/
format==/long/same thing as -l/
format==/single-column/same thing as -1/
format==/verbose/same thing as -l/
format==/vertical/same thing as -C/
option==/--full-time/list both full date and full time/
option==/-G --no-group/inhibit display of group information/
option==/-I --ignore=PATTERN/do not list implied entries matching shell PATTERN/
option==/-i --inode/print index number of each file/
option==/-k --kilobytes/use 1024 blocks, not 512 despite POSIXLY_CORRECT/
option==/-L --dereference/list entries pointed to by symbolic links/
option==/-l/use a long listing format/
option==/-m/fill width with a comma separated list of entries/
option==/-N --literal/print raw entry names (don't treat e.g. control characters specially)/
option==/-n --numeric-uid-gid/list numeric UIDs and GIDs instead of names/
option==/-o/use long listing format without group info/
option==/-p/append a character for typing each entry/
option==/-Q --quote-name/enclose entry names in double quotes/
option==/-q --hide-control-chars/print ? instead of non graphic characters/
option==/-R --recursive/list subdirectories recursively/
option==/-r --reverse/reverse order while sorting/
option==/-S/sort by file size/
option==/-s --size/print block size of each file/
option==/--sort=$sort/sorting order/
sort==ctime -c
sort==extension -X
sort==none -U
sort==size -S
sort==status -c
sort==time -t
option==/--time=WORD/atime -u, access -u, use -u/
option==/-T --tabsize=COLS/assume tab stops at each COLS instead of 8/
option==/-t/sort by modification time; with -l: show mtime/
option==/-U/do not sort; list entries in directory order/
option==/-u/sort by last access time; with -l: show atime/
option==/-w --width=COLS/assume screen width instead of current value/
option==/-x/list entries by lines instead of by columns/
option==/-X/sort alphabetically by entry extension/
option==/-1/list one file per line/
option==/--version/output version information and exit/

-- 
-russ <nelson@crynwr.com>  http://web.crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok |   Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice |   cause of Peace, Love,
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   |   Truth and Justice.