Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: silicono2 on 15 Nov 2005 20:46 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 15 Nov 2005 21:15 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 15 Nov 2005 21:47 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 15 Nov 2005 22:06 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 15 Nov 2005 22:56
"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 /\ |