From: silicono2 on
I've had a Unix-using acquaintance tell me that he much preferred
command lines over GUI, even when using Windows. For all the advantages
of GUI I agree that it's much easier to issue a series of commands in a
command line or do something like "copy *.* a:" as well. Can we get the
best of both worlds with an interface using charts/fields of text? The
only example I can think of is BIOS config (also DOSshell a while ago),
obviously it hasn't caught on.
Of course you can argue that a fields/charts interface is in fact a
GUI, with "true" graphics simply replaced by ASCII graphics?

Seb

From: John Hasler on
Seb writes:
> Can we get the best of both worlds with an interface using charts/fields
> of text?

No.
--
John Hasler
john(a)dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
From: Bill Marcum on
On 15 Nov 2005 17:46:11 -0800, silicono2(a)yahoo.com
<silicono2(a)yahoo.com> wrote:
> I've had a Unix-using acquaintance tell me that he much preferred
> command lines over GUI, even when using Windows. For all the advantages
> of GUI I agree that it's much easier to issue a series of commands in a
> command line or do something like "copy *.* a:" as well. Can we get the
> best of both worlds with an interface using charts/fields of text? The
> only example I can think of is BIOS config (also DOSshell a while ago),
> obviously it hasn't caught on.

If you like DOSShell or Norton Commander, try mc.


--
Santa's elves are just a bunch of subordinate Clauses.
From: Chris F.A. Johnson on
On 2005-11-16, silicono2(a)yahoo.com wrote:
> I've had a Unix-using acquaintance tell me that he much preferred
> command lines over GUI, even when using Windows. For all the advantages
> of GUI I agree that it's much easier to issue a series of commands in a
> command line or do something like "copy *.* a:" as well. Can we get the
> best of both worlds with an interface using charts/fields of text? The
> only example I can think of is BIOS config (also DOSshell a while ago),
> obviously it hasn't caught on.
> Of course you can argue that a fields/charts interface is in fact a
> GUI, with "true" graphics simply replaced by ASCII graphics?

There have been other attempts to do this, but there are good
reasons they didn't catch on.

I just read about two of them in an old (1988) book, Understanding
UNIX, A Conceptual Guide. It mentions ASSIST, "a menu-driven.
forms-based utility that helps the user construct Unix commands",
and Visual Shell in XENIX, "a menu-driven user interface patterned
after the MultiPlan spreadsheet".

In order to be a viable alternative to the command line, a menu
system would have to be huge and unwieldly. Imagine writing a
front-end to a command such as find without emasculating it.

--
Chris F.A. Johnson, author | <http://cfaj.freeshell.org>
Shell Scripting Recipes: | My code in this post, if any,
A Problem-Solution Approach | is released under the
2005, Apress | GNU General Public Licence
From: Robert Heller on
"Chris F.A. Johnson" <cfajohnson(a)gmail.com>,
In a message on Tue, 15 Nov 2005 22:06:40 -0500, wrote :

"FJ> On 2005-11-16, silicono2(a)yahoo.com wrote:
"FJ> > I've had a Unix-using acquaintance tell me that he much preferred
"FJ> > command lines over GUI, even when using Windows. For all the advantages
"FJ> > of GUI I agree that it's much easier to issue a series of commands in a
"FJ> > command line or do something like "copy *.* a:" as well. Can we get the
"FJ> > best of both worlds with an interface using charts/fields of text? The
"FJ> > only example I can think of is BIOS config (also DOSshell a while ago),
"FJ> > obviously it hasn't caught on.
"FJ> > Of course you can argue that a fields/charts interface is in fact a
"FJ> > GUI, with "true" graphics simply replaced by ASCII graphics?
"FJ>
"FJ> There have been other attempts to do this, but there are good
"FJ> reasons they didn't catch on.
"FJ>
"FJ> I just read about two of them in an old (1988) book, Understanding
"FJ> UNIX, A Conceptual Guide. It mentions ASSIST, "a menu-driven.
"FJ> forms-based utility that helps the user construct Unix commands",
"FJ> and Visual Shell in XENIX, "a menu-driven user interface patterned
"FJ> after the MultiPlan spreadsheet".
"FJ>
"FJ> In order to be a viable alternative to the command line, a menu
"FJ> system would have to be huge and unwieldly. Imagine writing a
"FJ> front-end to a command such as find without emasculating it.

Right. For some commands (such as find), there is no real chance of
ANY viable 'graphical' interface. And for others a CLI interface might
make no sense. The only sort of 'best of both worlds' is a GUI desktop
that includes an 'shell window' (xterm+shell).

The only sort of 'unifying' interface is going to be an *intelligent*
voice-recognition / natural-language type of interface, ala Star Trek.

One way of thinking about the differences between a GUI (aka
'point-and-click') and a CLI and how they relate to how effectively one
can communicate with one's computer to get stuff done is to consider
that a GUI interface is not really much different than a pre-lingual
communication system. One can replace 'point-and-click' with
'point-and-grunt' (ala proto-humans) or 'point-and-scream' (ala
infants). In all of these cases, the communication is limited to the
choices at hand, literally (the finite and *limited* set of things
available on the screen). A CLI interface is not so limited. It has
all of the advantages of a full blown language and can refer to things
that are 'off screen' (things that are not visible).


"FJ>
"FJ> --
"FJ> Chris F.A. Johnson, author | <http://cfaj.freeshell.org>
"FJ> Shell Scripting Recipes: | My code in this post, if any,
"FJ> A Problem-Solution Approach | is released under the
"FJ> 2005, Apress | GNU General Public Licence
"FJ>

\/
Robert Heller ||InterNet: heller(a)deepsoft.com
http://www.deepsoft.com/ ||FidoNet: 1:321/153
http://www.deepsoft.com/~heller /\