command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: silicono2 on 18 Nov 2005 18:12 Michael Heiming wrote: [snip] > Hi! > > We don't know to whom or in which context you are talking, unless > you quote the article probably you are following up to. > > Please read this before posting anything else: > > http://cfaj.freeshell.org/google > > Good luck > > -- > Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94) > mail: echo zvpunry(a)urvzvat.qr | perl -pe 'y/a-z/n-za-m/' > #bofh excuse 153: Big to little endian conversion error Phew, that's better. Thanks for the netiquette heads-up. Seb
From: Reinder Verlinde on 18 Nov 2005 19:11 In article <m2u0eax8w9.fsf(a)hugin.crs4.it>, Jacob Sparre Andersen <sparre(a)nbi.dk> wrote: > Reinder Verlinde wrote: > > I would say that some (all?) of the fundamental differences between > > shell and gui are: > > > > - a shell requires one to memorize available options, whereas a GUI > > allows you to easily discover them > > That is not the case with the shell I use (Zsh). A press on the > tabulator key will generally (unfortunately not always) give me a list > of available commands/options/files. > [...] > You should take a look at Zsh and see if you really think the > description "in its infancy" is proper. Thanks for that pointer. Zsh indeed seems to offer better completion than other shells I know of. However, on my system (Mac OS X without any effort from my side to configure Zsh), I would not say that it 'generally' gives me a list of available commands/options/files. For example, the first tool I tried is rmdir. Zsh did not inform me about its '-p' option, and erroneously listed all files in my home directory as arguments. It appears that one can correct this, though. However, I have not been able to find out how to do that in about an hour with 'man' and google. > > - Apple's commando interface that allowed one to pop up a GUI-dialog > > with which one could both see and set all options for a command > > That's a nice idea. Another nice idea (I can't remember _where_ I saw > it) is to let a GUI generate commands in the shell. That allows the > user to take the generated commands and generalize them as needed. commando did that, too. (aslo, it got all information it needed from the executable file itself. That decreased the risk of getting a mismatch between what a command accepted and what commando thought it accepted. If that idea had caught on, zsh could auto-configure itself) > > - Microsoft's upcoming shell that gets rid of text as the I/O format. > > I'm not exactly sure how that can be said to be an improvement. > Formally adding other content types is a good idea (in practice it has > already been done a long time ago), but removing text as an I/O format > seems to remove a lot of the possibilities you have with shells. The preferred I/O format in the new Windows shell seems to be a sort of SQL table. The shell auto-converts these to text when showing them to the user. For instance, <http://arstechnica.com/guides/other/msh.ars/4> gives the following example: msh> get-childitem | sort-object extension | select extension | where { $_.extension.length -eq 4 } to list all four-character file extensions in the current directory in alphabetical order The text/Unix 'equivalents' for these commands would be: get-childitem ~= ls sort-object ~= sort select ~= cut where ~= grep but there is no way I can see to extract those file extensions from ls. Also, I think the windows shell is more readable and more maintainable. Reinder
From: Reinder Verlinde on 18 Nov 2005 19:12 In article <437df494(a)news.orcon.net.nz>, Benni <not(a)interesting.com> wrote: > Reinder Verlinde wrote: > > > - Microsoft's upcoming shell that gets rid of text as the I/O format. > > Never seen a UNIX shell? I do not understand your remark. Can you elaborate on it? Reinder
From: Lee Sau Dan on 18 Nov 2005 21:13 >>>>> "Tobias" == Tobias Brox <tobias(a)stud.cs.uit.no> writes: Tobias> [Lee Sau Dan] >> It's not hard to come up with a front-end to 'find'. e.g. >> Command: [find ] Arg 1: [/home/foo ] Arg 2: [-name ] Arg 3: >> [*.txt ] [Add More Args] [Go] >> But I bet you'll prefer the CLI to such a GUI, won't you? Tobias> I could do better than that. Tobias> First of all, we already have simple command-line Tobias> completion. It can also be extended to "smart" Tobias> command-line completion, i.e. you write "find /home/foo Tobias> -n<tab>" and the command line completer would suggest Tobias> "-name". Indeed, you could customize bash'es completion to do that by using the "complete" command. e.g. "cd <TAB>" would only suggest directory names (no file names); "xpdf <TAB>" would only suggest filenames ending in .pdf. Here's an excerpt from the man page: complete -pr [name ...] Specify how arguments to each name should be completed. If the -p option is supplied, or if no options are supplied, existing completion specifications are printed in a way that allows them to be reused as input. The -r option removes a completion spec- ification for each name, or, if no names are supplied, all com- pletion specifications. But of course, there are still rooms for improvement. But... would people consider such a thing still a CLI or a GUI? Tobias> Secondly, a [gt]ui/cli-tool that are aware of find, would Tobias> of course have find as a menu option, it would allow the Tobias> user to chose what directories to search, and it would Tobias> have a pull-down-menu of all the possible parameters to Tobias> find, complete with help text and boxes for filling out Tobias> arguments. Tobias> This would help immensely for people who need to use find, Tobias> but which does not remember the syntax/commands, and/or Tobias> doesn't have the patience to RTFM. They don't have the patience to RTFM. But they have the patience to go through menus, checkboxes, comboes and cascading dialog boxes? Tobias> Piping could also be solved through a GUI, I think. Given that you can enter 0 and 1 using the mouse only in a GUI, what can't be done? Efficiency is the issue here. Tobias> But why bother, people who are smart enough to see the use Tobias> of piping are usually also smart enough to get around in Tobias> the CLI ;-) That's the point. GUI users: why do you use the CLI? children riding tricycles: why are you riding a bike with 2 wheels only? people driving a motor boat: why would you go yachting? -- Lee Sau Dan §õ¦u´° ~{@nJX6X~} E-mail: danlee(a)informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee
From: Lee Sau Dan on 18 Nov 2005 21:22
>>>>> "Tobias" == Tobias Brox <tobias(a)stud.cs.uit.no> writes: Tobias> Turtle graphics is also a nice one, like turtle.py or the Tobias> old logos programming language. Drawings are made by Tobias> commands; like, to draw a 6-fold star one could do things Tobias> like: Tobias> repeat 2: Tobias> repeat 3: Tobias> forward 160 Tobias> right 120 degrees Tobias> left 30 degrees Tobias> pen up Tobias> forward 80 Tobias> pen down Tobias> right 90 degrees Tobias> (find one error) What? This language relies on INDENTATION to tell the boundary of a repeat block? i.e. repeated whitespace characters affect semantics? That'd be very error prone! Tobias> Now, using python and i.e. turtle.py almost anyone can Tobias> start making complicated drawings and user-defined Tobias> subroutines. Another reason that I like metapost is that I can group repeated blocks into macros (== procedures or functions in other languages). The macros can even be parameterized. This not only saves typing, but also makes the code more maintainable. And macros are an easy way to ensure consistency in style of the drawings. Macros can also be grouped into a separate file that is included from a main source file (akin to C/C++ #include). So, if I want to change the colours of my arrows, I just need to modify my arrowstyle.mp which is included by other files. Then, a recompilation (facilitated by 'make') will update all diagrams with the new colour scheme. No need to tediously go through the diagram one by one. Tobias> As for exactness, the very most drawing programs supports Tobias> "snap to grid", and that's usually sufficient for me (not Tobias> that I make many drawings anyway). "snap to grid". So, you must place your drawing points at integral multiple of the grid granularity. Then, it can't let you accurately start/end an arrow at the circumference of a circle, which has a radius that is an integral multiple of the grid granuarity, at the point which is 45 degrees counterclockwise from the x-axis. -- Lee Sau Dan §õ¦u´° ~{@nJX6X~} E-mail: danlee(a)informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee |