command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Peter T. Breuer on 9 Dec 2005 06:36 In comp.os.linux.misc blmblm(a)myrealbox.com wrote: > In article <3osm63-kcg.ln1(a)news.it.uc3m.es>, > Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >>In comp.os.linux.misc Tobias Brox <tobias(a)stud.cs.uit.no> wrote: >>> - While Breuer is correct that any boolean expression can be >>> normalized, I think he is overlooking that it's actually possible >>> to mix _actions_ into the boolean expressions given to find - and >>> honestly, I also overlooked that. I think a boolean expression >>> with side effects cannot be normalized. Particularly the "prune" >>> action is not catered for in the interface below. >> >>That's true - but then it's an ill-thought out feature of find in the >>sense that the extra complexity allowed by embedding various execs at >>once in a search expression is not wanted. What they MEANT to do was >>apply an action at each of the selected subset of nodes and leaves in >>the file hierarchy. >> >>That's simply a final coup-de-grace on the end of the filter chain. > I don't seem to be very good at comprehending your meaning from your > written words, but oh well, one more try .... > "find" allows me to search a hierarchy for files that match criterion > A or criterion B, and apply action AA to the ones that match A > and action BB to the ones that match B. As far as I can tell, > this is not possible with your proposed GUI. It requires two searches and one (different) action applied to the (stored) resulting list from each search. Or if you prefer, it requires one (union) search with -ls applied as the action, and one filter on the list of results to do a single compound action predicated appropriately on the ls output line. > I *think* what you're saying is that it doesn't need to be (possible > with your GUI), because no one actually wants to do what I just > described, and so the fact that "find" allows it is poor design. Yes. Peter
From: blmblm on 9 Dec 2005 07:00 In article <7r6o63-v15.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc blmblm(a)myrealbox.com wrote: [ snip ] >> "find" allows me to search a hierarchy for files that match criterion >> A or criterion B, and apply action AA to the ones that match A >> and action BB to the ones that match B. As far as I can tell, >> this is not possible with your proposed GUI. > >It requires two searches and one (different) action applied to the >(stored) resulting list from each search. So, your proposed GUI also needs to be able to store its results for later processing? Okay. Or maybe you're just saying "do two separate searches". Which is probably what most people would do anyway, and in fact the only benefit I can think of in doing it as I originally described is that the combined search would only have to traverse the directory structure once. >Or if you prefer, it requires one (union) search with -ls applied >as the action, and one filter on the list of results to do a single >compound action predicated appropriately on the ls output line. I'm having some trouble imagining how this would work with a GUI. You'll need some way of describing this compound action, no? Let's try an example: find $HOME -name "*.bak" -exec rm {} ; -o -mtime -1 -ls A union search will give me a list of files, some ending ".bak" and some modified in the past 24 hours. Describing the compound action .... "If filename matches '*.bak' then remove it, otherwise print full -ls information about it"? But my examples do seem to be wandering into that "no one would want to do this!" territory so familiar from other preposterous "can your GUI do this?!" examples. [ snip ] -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: Lee Sau Dan on 9 Dec 2005 12:22 >>>>> "blmblm" == blmblm <blmblm(a)myrealbox.com> writes: >> It's possible to make shortcuts, tab completion, history >> buffers w/ interactive search (ctrl-R) and scripts in command >> line mode. All tasks that I do relatively often is done very >> quick from the CLI. blmblm> As do I. I'm pretty sure I wouldn't be such an advocate blmblm> of a CLI without these features. >> I'm pretty sure it would be slower using _any_ gui. blmblm> That's what I generally assume too, but I vaguely remember blmblm> hearing about a study Apple conducted many years ago that blmblm> demonstrated that people *think* a CLI is faster, but if blmblm> you do actual measurements of how long tasks take, it blmblm> turns out the point and click is as fast or faster. No, I blmblm> don't (want to) believe it, but it could be true?? Did that CLI that was used in that study have those features such as context-sensitive TAB completion, history buffer with interactive search, etc? I would be very very slow if you give me the MSDOS shell. But why would you make a serious comparing with that shell? -- 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 9 Dec 2005 12:26 >>>>> "Robert" == Robert M Riches <spamtrap42(a)verizon.net> writes: Robert> I'd be a bit skeptical of their supposed "study". The HCI Robert> folks are not immune to misconceptions and incorrect Robert> prejudices, either. A few years ago, I took a Robert> master's-level course titled something similar to Robert> "Introduction to Human Computer Interaction". The text Robert> spent a great deal of time preaching that the mouse was Robert> the only useful way to enter positional information, and Robert> no trackball could ever be built that would have any Robert> degree of speed or precision. Heard of digitizers, which the real professionals doing CAD/CAM often use? Robert> Reality is I can get much better speed and precision Robert> with my Logitech Trackman Marble than I can with a mouse, Robert> and much better than the figures the textbook quoted for Robert> mouse input. You can do even better with digitizers. Robert> On top of that, I don't have to deal with any of the Robert> very serious disadvantages of a mouse. It seems that the course instructor is quite ignorant about input devices. Has he ever seen any input device beside keyboards and mice (and perhaps joysticks)? Robert> Besides, it's going to be a little difficult to take a GUI Robert> sequence and put it in a crontab to run at 2:30am monday Robert> through friday without turning the GUI into a CLI. That's why the CLI won't go away. -- 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 9 Dec 2005 12:32
>>>>> "Dances" == Dances With Crows <danSPANceswitTRAPhcrows(a)gmail.com> writes: >> A few years ago, I took a master's-level course titled >> something similar to "Introduction to Human Computer >> Interaction". The text spent a great deal of time preaching >> that the mouse was the only useful way to enter positional >> information, and no trackball could ever be built that would >> have any degree of speed or precision. Dances> Textbook authors can be dumb too. (Or maybe this is like Dances> what Stephen Jay Gould described in "The Case of the Dances> Creeping Fox Terrier Clone".) Dances> Hm, did they look at Trackpoints? Or graphics tablets? Apparently not. Dances> They might not have; don't want to confuse the students Dances> with lots of data that may or may not support the point Dances> the author was trying to make. People with that mindset won't be good instructors. And their courses are rubbish. Sounds that the course is very business in nature: to earn money from students by giving them good grades as long as they pay. Not meant to be a course to teach the students. Dances> Or they did something like what Apple did at the Dances> beginning of MacOS: Put a bunch of random people in front Dances> of a machine with a mouse and a trackball, see which Dances> device they like better. Using experienced users instead Dances> of random people would definitely produce different Dances> experimental data. Didn't Apple have touch-screen versions of Mac pretty early? I've seem some no later than 1990. I'd guess that a novice user would prefer touch-screen to mouse or trackball. >> Besides, it's going to be a little difficult to take a GUI >> sequence and put it in a crontab to run at 2:30am monday >> through friday without turning the GUI into a CLI. Dances> xmacrorec, then xmacroplay? Does it only emulate the clicks and mouse movements? In that case, it won't be reliable. What if you now run the macro under a different resolution, so that the fonts have slightly changed and the buttons have been resized to something different from the sizes when the macro was recorded? Or the program would show different sets of GUI buttons at different times of the day, or different days of the week? Dances> OK, that won't work unless the widgets you're clicking on Dances> don't move around, So fragile. Dances> but it's certainly possible to do if you really have to. Dances> Or you could hack something up using wmctrl, but that's Dances> probably too close to "turning the GUI into a CLI". No. The precision is lost. You can't specify the operations precisely. So, the script is no longer reliable. -- Lee Sau Dan §õ¦u´° ~{@nJX6X~} E-mail: danlee(a)informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee |