On Tue, Apr 08, 2014 at 03:14:58PM -0700, Kevin Ballard wrote: > On Apr 8, 2014, at 3:12 PM, glphvgacs <darwinsker...@gmail.com> wrote: > > > On Tue, Apr 08, 2014 at 02:53:16PM -0700, Kevin Ballard wrote: > >> I am having a hard time figuring out what you're trying to say here. > >> The only thing I got with any certainty is that you think that hitting > >> <enter> should auto-accept the suggestion. That's an incredibly > >> dangerous and surprising behavior to put into a terminal shell. For > >> example, `rm f` should _never_ automatically invoke `rm f*`. > >> > >> -Kevin > > > > hello, > > i don't think you have that one either. > > > > rm -rf /<Enter> > > > > will execute 'rm /' in any shell anyway. > > Well yes, because that's what I asked it to do.
what is the difference between that case and when the rest of the line is *filled-in* by the suggestion engine then? users sees what's to be executed and then hits the enter. i would argue that, in majority of cases, it's safer to run commands from history to run then for the first time since you have already run that command, this is the second time and a quick check should suffice. > > > question then is why would suggestion engine bring that up. > > > > in any case, there are two things that i'm asking about: > > 1. prioriotising the auto-completion/auto-suggestion's > > this is exactly what vimperator or pentadactyl do in firefox. > > so user could set auto-suggestions-order e.g. in this order: > > > > set auto-suggestion-order=history,cmd,path > > > > then history would be offered first and cmd next, with a delim in > > between perhaps, and so on. > > so in that case if user has already run 'rm -rf / ' he doesn't get a > > second chance :) > > kidding aside, since history are the commands that have already been > > checked and run there is a level of safetly in repeating them where as > > in other shells you always have to check for type everytime. > > > > 2. accepting the first *hit* with an <Enter> > > this exactly what Safari's or chrome's address bar do. > > hit being the first match for the input so far and vimperator did not > > offer this last time i checked. > > Web browser behavior is _completely unrelated_ to shell behavior. they are both command-line interface, of course they're related. > Whether or not it's appropriate for a web browser to auto-accept its > first suggestion when you type a URL has no bearing whatsoever on > whether it's appropriate for a shell to accept its first suggestion > when you hit enter. now that's unrelated since it's like comparing apples and oranges. i gave vimperator as something to illustrate my point. (not a native en speaker). > Among other reasons, the likelihood that the browser's suggestion is > correct is vastly higher than the likelihood that the shell's > suggestion is correct, i don't agree. shell searches the str's in history and so does the browser. it's the user that *builds* both of those histories so the level of accuracy is pretty much the same, taking both have well-written engine to find the str. > and the negative effects of auto-accepting the > first history suggestion in a browser is effectively zero whereas the > negative effects of auto-accepting the first suggestion in a shell are > potentially catastrophic. > like i mentioned above you could say exactly the same thing for the first run of the command. why would shell let users run anything then? it is safer to fill-in stuff from history because it's _at least_ the second time that user is going to run the command and if it was catastrophic the first time around and he is doing it again, well then PICNIC. ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users
