Yeah, sure. So I can have users "losing" entire directories. I will never forget the time I was called frantically to restore accounting information to someone's server because it was "missing". It being on NetWare I attempted a Salvage, but couldn't find anything to salvage. Well Chief, to make a long story short, someone had dragged the directory into one of the surrounding subdirectories. While Konqueror would have asked "Move, Copy, Link", Exploder didn't think to and simply moved it. DOH!
begin "Mike Andrew" <[EMAIL PROTECTED]> (Sat, 9 Feb 2002 14:00:20 +1130) > On Wed, 6 Feb 2002 05:21, Bill Campbell wrote: > > > I learned a long time ago (1) to always ``cd'' to a directory before doing > > an ``rm *'' in that directory instead of ``rm dir/*'' since a space after > > the slash does nasty things, and (2) to think really hard before using the > > ``*'' to make sure I've typed it correctly. > > This is where a gui widget helps. A delete widget (button or icon) is context > sensitive, it might operate on some highighted info, or many other criteria. > The only thing context sensitive about the cli method is the current path > (dot)(slash) > > A gui widget learns from it's mistakes. Ie it is automated better by each > iteration of the code underlying it. It might do self checks, it might > 'understand' what can / can't be deleted, it might be full bloat and actually > do hidden backups. Point being, it can be automated with intelligence. The > same intelligence you have to 'learn', it can too. The difference is the gui > widget is an accumulator of knowledge. It doesnt forget, or make typos, or > unlearn. You can create this fundamental, identically, using cli script. Ie > overwriting the basic rm command with an alias to a written script of your > own which would exhibit the same strengths as a gui-widget (because basically > all scripts are widgets). Where the gui method differs is that all possible > options (can be) presented in your face so to speak, with radio buttons or > check boxes. There's nothing different about using 'no operator intelligence > required' gui button and an equally 'no intelligence required' script. Both > are implemented with the same goal in mind. But give me a gui anyday to > remove the typos, and remind me, of all possible options that I can't > remember, or much much worse, how to present them, on the command line. > > Secondly, a gui widget is a token. A picture of a crimson pink elephant > means something. awk, grep, Grep, grEp, GRep, and grePpp mean nothing and are > impossible to remember (the classic cp -r ... and chown -R .....) > > Using a mouse (gui), or, using the up-arrow (cli), has the same degree of > laziness, except mice can't type miStakeZ. The idea of 'you can type the > command quicker and easier', frankly, fills me with horror. Been there dun > that, and recovered. SOME installations ban all use of the cli for this > reason. (VisaCard servers eg). *nix makes much of the security aspect "linux > won't let you.....". This is fuddelbunk when it comes to individual users. > Linux very weak in protecting a user from himself. The idea that a scientist > deleting his 2,000 page thesis by accident is 'too stupid to use a computer' > doesn't wash well. Up arrows create havoc each day every day. > > One final thing to say about gui widgets is there is a disconnect between the > command option and the literal. With cli, once you determine that --elephants > means ignore timeouts, that's it. In most cases, 'elephants' is position > sensitive as well. You can't change the name, nor it's position relative to > other commands (without serious wurries). Filenames are particularly > notorious, eg copy this = that, or is it copy that->this ? > > With a gui, the visual front end can be radio-button-"elephants" and next > version radio-button:"giraffes" if that has more contextual sense, and > options have no position sensitivy. A text box saying "input file name" is > pretty clear. This means that revision of a gui widget doesn't automatically > break the underlying code, nor, does it inhibit revision. The dangers > inherent in changing how a cli verb operates has indeed prevented many of > them from being revised and is the reason why we cannot have a uniform set of > -a, -b -c switches. They can't even agree on --help, /h -h, --H, -i, --I, -v > or -vV. The F1 key is agreed on. > > -- > http://linux.nf -- [EMAIL PROTECTED] > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Linux-users mailing list - http://linux.nf/mailman/listinfo/linux-users > Subscribe/Unsubscribe info, Archives,and Digests are located at the above URL. -- Matthew Carpenter [EMAIL PROTECTED] http://www.e-i-s.cc/ Enterprise Information Systems *Network Consulting, Integration & Support *Web Development and E-Business _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Linux-users mailing list - http://linux.nf/mailman/listinfo/linux-users Subscribe/Unsubscribe info, Archives,and Digests are located at the above URL.
