[opensuse-factory] issues with command-not-found speed
Hello! Yesterday I have found out that from time to time, when I type a typo, it takes a huge amount of time until a "command of found message" appears and I can continue my work. Now I am able to reproduce it every time on my rc1 machine:
time sl bash: sl: command not found
real 0m1.289s user 0m0.228s sys 0m0.040s Typing "echo 1 >/proc/sys/vm/drop_caches" enables me to reproduce it every time (not doing it means that it happens at random). I am quite sure that our command-not-found package is to blame. I do not know how come it is that slow (I have only some five repositories defined) but it kind of drives me mad. So first - could you tell me a way to disable this functionality? (Commenting out the last line in /etc/bash_command_not_found does not seem to help.) And then, are there any known issues like that? I would like to see this problem fixed but I am afraid we might find out that we simply cannot do any better with Python. If our users like it, we should probably rewrite it to C then :-( Anicka -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Anicka Bernathova wrote:
Hello!
Yesterday I have found out that from time to time, when I type a typo, it takes a huge amount of time until a "command of found message" appears and I can continue my work.
Now I am able to reproduce it every time on my rc1 machine:
time sl bash: sl: command not found
real 0m1.289s user 0m0.228s sys 0m0.040s
Typing "echo 1 >/proc/sys/vm/drop_caches" enables me to reproduce it every time (not doing it means that it happens at random).
I am quite sure that our command-not-found package is to blame. I do not know how come it is that slow (I have only some five repositories defined) but it kind of drives me mad.
So first - could you tell me a way to disable this functionality? (Commenting out the last line in /etc/bash_command_not_found does not seem to help.) And then, are there any known issues like that? I would like to see this problem fixed but I am afraid we might find out that we simply cannot do any better with Python.
If our users like it, we should probably rewrite it to C then :-(
Anicka
You can try profile that script(http://www.python.org/doc/2.5.2/lib/profile-instant.html) and find what slow down it. I can say, that this script doesn't slow down my console. JR -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Anicka Bernathova wrote:
Hello!
Yesterday I have found out that from time to time, when I type a typo, it takes a huge amount of time until a "command of found message" appears and I can continue my work.
Now I am able to reproduce it every time on my rc1 machine:
time sl bash: sl: command not found
real 0m1.289s user 0m0.228s sys 0m0.040s
That's weird. Try running zypper refresh -f (forces a complete refresh including rebuild of the database) and "benchmark" again.
Typing "echo 1 >/proc/sys/vm/drop_caches" enables me to reproduce it every time (not doing it means that it happens at random).
That's what caches are for: to cache data. If you keep dropping them, performance of the programs will be worse.
I am quite sure that our command-not-found package is to blame. I do not know how come it is that slow (I have only some five repositories defined) but it kind of drives me mad.
So first - could you tell me a way to disable this functionality?
Put unset command_not_found_handle in your profile. Or simply uninstall the command-not-found package.
And then, are there any known issues like that? I would like to see this problem fixed but I am afraid we might find out that we simply cannot do any better with Python.
If our users like it, we should probably rewrite it to C then :-(
Read https://bugzilla.novell.com/show_bug.cgi?id=435160 You will learn that rewrite to C would be of no use, because Python code immediately calls wrapped satsolver library which IS written in C. And most of time (if not all of it) is spent there ... -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 10 of December 2008 10:44:40 Pavol Rusnak wrote:
Anicka Bernathova wrote:
If our users like it, we should probably rewrite it to C then :-(
Read https://bugzilla.novell.com/show_bug.cgi?id=435160
You will learn that rewrite to C would be of no use, because Python code immediately calls wrapped satsolver library which IS written in C. And most of time (if not all of it) is spent there ...
But now is possible, that anicka is right. I modified the search method of bin.py: def search(self, term): return [] so it didn't calls a satsolver, but the first run with dropped cache is still slow. $ time sl bash: sl: command not found real 0m1.546s user 0m0.196s sys 0m0.056s -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Michal Vyskocil wrote:
But now is possible, that anicka is right. I modified the search method of bin.py: def search(self, term): return []
so it didn't calls a satsolver, but the first run with dropped cache is still slow.
Repo SOLV files are read in SolvParser constructor not in its search() method. Search for the line: repo = self.pool.add_solv( self.solvfile % name ) -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
That's weird. Try running
zypper refresh -f (forces a complete refresh including rebuild of the database)
and "benchmark" again.
No help here.
That's what caches are for: to cache data. If you keep dropping them, performance of the programs will be worse.
Sure. I will not mind if the case with dropped cache will be slower. But I think that it also must not be horribly slow. More than a second _is_ horribly slow and I cannot really choose that my caches will just work for me in most of the cases. I am doing it to reproduce the problem consistently but it happens even if I do not care. And even initiation of ssh connection to my slow-networked home machine is much faster then. And even installing the package sl and running this command is only three times slower and much more fun ;-)
You will learn that rewrite to C would be of no use, because Python code immediately calls wrapped satsolver library which IS written in C. And most of time (if not all of it) is spent there ...
Too bad. Look: This is a tool for a bash users and we have a good reason to believe that people using bash are people who are not willing to loose their time with fancy GUI tools. We want to help them with their work and help them when they do a mistake, fine. But exchange of help that probably will not be needed for a apparent delay in many cases when a typo is typed is no real help. command-not-found message with all the information in 0.3 seconds is a cool thing to have. Message appearing in 1.3 seconds makes this package just another kludge that needs to be uninstalled from the default installation, when you want to have your work done. I got used to uninstalling mono, apparmor and similar highly useful tools for my daily work. I am very unhappy that we have yet another thing like that. If this tool has to be that slow by design, I think that it should not be present in default installation (again: bash users are IMHO mostly people who want to have their work done, no need to help them). Otherwise it should be fixed. Anicka -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2008-12-11 at 11:51 +0100, anicka@suse.cz wrote:
Too bad. Look: This is a tool for a bash users and we have a good reason to believe that people using bash are people who are not willing to loose their time with fancy GUI tools. We want to help them with their work and help them when they do a mistake, fine.
But exchange of help that probably will not be needed for a apparent delay in many cases when a typo is typed is no real help. command-not-found message with all the information in 0.3 seconds is a cool thing to have. Message appearing in 1.3 seconds makes this package just another kludge that needs to be uninstalled from the default installation, when you want to have your work done.
How about: If the info is not provided within, say, 0.3 seconds, abort, say "not found", plus "issue 'infoonlastcommandnotfound' and we'll try to provide you with some extra info". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklBB6cACgkQtTMYHG2NR9Wy8QCeMZBpA/Re8Ej2ThcOyJDGGl1w GwIAnRn6s+ZAarcmZOXlaQ2G0FYd12CG =QVN2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
anicka@suse.cz wrote:
You will learn that rewrite to C would be of no use, because Python code immediately calls wrapped satsolver library which IS written in C. And most of time (if not all of it) is spent there ...
Too bad. Look: This is a tool for a bash users and we have a good reason to believe that people using bash are people who are not willing to loose their time with fancy GUI tools. We want to help them with their work and help them when they do a mistake, fine.
You are probably aware of it, but just to make it clear for other list readers: command-not-found is not GUI. It just prints some text to console.
But exchange of help that probably will not be needed for a apparent delay in many cases when a typo is typed is no real help. command-not-found message with all the information in 0.3 seconds is a cool thing to have. Message appearing in 1.3 seconds makes this package just another kludge that needs to be uninstalled from the default installation, when you want to have your work done.
When it provides useful information which missing package to install just in 1.3 seconds, it is a great enhancement, don't you think? I agree that 1 second could be bothersome when you do a typo, though. Unfortunately there is no easy way to figure out if the command written is a typo or not. More easier approach is to do less typos :) (Especially in shell they can be dangerous).
I got used to uninstalling mono, apparmor and similar highly useful tools for my daily work. I am very unhappy that we have yet another thing like that.
Just add command-not-found to your list then. It seems wide already. (Or change you shell profile, you wouldn't need to bother with this issue anymore).
If this tool has to be that slow by design, I think that it should not be present in default installation (again: bash users are IMHO mostly people who want to have their work done, no need to help them). Otherwise it should be fixed.
Shell users are the ONLY people which will use this tool, so argument 'no need to help them' is far off. Command-not-found could not be used from anything else than shell. I sure hope that advanced bash users (the ones you are probably referring to, not all bash users) are able to add 'unset command_not_found_handle' to their profiles. For my part, I really don't care if c-n-f is a part of default install or not. I know how that the tool exists and how to install it. The question is: Do we want our users to know about it? Do we care about their experience? Do we want a head start on the competition? If there is more negative response, c-n-f will not be installed by default. If there is more positive acceptance, it will stay. If we hadn't enabled it by default now, we would have never known. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
For my part, I really don't care if c-n-f is a part of default install or not. I know how that the tool exists and how to install it. The question is: Do we want our users to know about it? Do we care about their experience? Do we want a head start on the competition? If there is more negative response, c-n-f will not be installed by default. If there is more positive acceptance, it will stay. If we hadn't enabled it by default now, we would have never known.
That is actually why I have started this discussion in public, after all :-) The other thing is that I just kind of could not believe at first that any reasonably well written software can be that horribly slow on my otherwise wonderfully fast workstation. What does it really have to do, search in ~1M of filenames? Is it really that much? I do not really know, and I might not know what it is all about, I am just asking. But I thought that searching could be done much faster on recent hardware. Anicka -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2008-12-11 at 13:41 +0100, Pavol Rusnak wrote:
I sure hope that advanced bash users (the ones you are probably referring to, not all bash users) are able to add 'unset command_not_found_handle' to their profiles.
I suggest you add that info as a comment to the default profile - same as there is a comment on "fortune". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklBDwcACgkQtTMYHG2NR9Xd2QCggl1WjxwR1VEb4Tmt8FLkYqO3 vQQAn0d/soj86mF2kt4KeXOYnaO7fODp =YdG6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
anicka@suse.cz wrote:
For my part, I really don't care if c-n-f is a part of default install or not. I know how that the tool exists and how to install it. The question is: Do we want our users to know about it? Do we care about their experience? Do we want a head start on the competition? If there is more negative response, c-n-f will not be installed by default. If there is more positive acceptance, it will stay. If we hadn't enabled it by default now, we would have never known.
That is actually why I have started this discussion in public, after all :-)
The other thing is that I just kind of could not believe at first that any reasonably well written software can be that horribly slow on my otherwise wonderfully fast workstation. What does it really have to do, search in ~1M of filenames? Is it really that much?
I do not really know, and I might not know what it is all about, I am just asking. But I thought that searching could be done much faster on recent hardware.
Anicka
Because you are packager, I expect you have tons of repositories and what must solver do, is search through cache of this repositories. And because cache is not used only for this command, but also for other purpose like installation of software, It contain quite much data and is adequate big. So you can create own cache based on that repositories or decrease search space. JR -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 11 of December 2008, anicka@suse.cz wrote:
For my part, I really don't care if c-n-f is a part of default install or not. I know how that the tool exists and how to install it. The question is: Do we want our users to know about it? Do we care about their experience? Do we want a head start on the competition? If there is more negative response, c-n-f will not be installed by default. If there is more positive acceptance, it will stay. If we hadn't enabled it by default now, we would have never known.
That is actually why I have started this discussion in public, after all :-)
I personally think that if you run into the feature and don't want it, it's just a matter of it happening once and then you uninstall it, but the other way around it may mean that you never see it even if you'd find it useful. Especially considering what kind of users should be the first and second case.
The other thing is that I just kind of could not believe at first that any reasonably well written software can be that horribly slow on my otherwise wonderfully fast workstation. What does it really have to do, search in ~1M of filenames? Is it really that much?
I do not really know, and I might not know what it is all about, I am just asking. But I thought that searching could be done much faster on recent hardware.
Unless you have SSD as your disk in the machine, your recent hardware is not wonderfully fast as long as you have anything non-trivial that needs reading from disk. Even just starting bash takes a short while after you drop disk caches. -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
anicka@suse.cz wrote:
The other thing is that I just kind of could not believe at first that any reasonably well written software can be that horribly slow on my otherwise wonderfully fast workstation. What does it really have to do, search in ~1M of filenames? Is it really that much?
I do not really know, and I might not know what it is all about, I am just asking. But I thought that searching could be done much faster on recent hardware.
Read the bugreport I mentioned earlier. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
anicka@suse.cz writes:
Too bad. Look: This is a tool for a bash users and we have a good reason to believe that people using bash are people who are not willing to loose their time with fancy GUI tools. We want to help them with their work and help them when they do a mistake, fine.
I'd very much prefer bash to tell me without any delay: Command not found. If this is not a typo, see make-it-work(1) for help. And then the make-it-work man page will tell you right away to run "make-it-work commandname' to locate and install the package providing fancytool. Seasoned shell kiddies will go one back in history, prefix their last command with 'make-it-work ' and have fun... imho the current solution is solving a problem that doesn't really exist (pretend all software is preinstalled) and creates a new one (lag). my .02 EUR S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 11 December 2008, Pavol Rusnak wrote:
anicka@suse.cz wrote:
The other thing is that I just kind of could not believe at first that any reasonably well written software can be that horribly slow on my otherwise wonderfully fast workstation. What does it really have to do, search in ~1M of filenames? Is it really that much?
I do not really know, and I might not know what it is all about, I am just asking. But I thought that searching could be done much faster on recent hardware.
Read the bugreport I mentioned earlier.
-- Best Regards / S pozdravom,
Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz
I am no developer but is all this worth it for a single second i mean really not because it would cause you major headaces (which i doubt) is it really worth all the hassle you dont like/want it simple turn it off . There are other things that are in far greater need of speed improvments Pete . -- SuSE Linux 10.3-Alpha3. (Linux is like a wigwam - no Gates, no Windows, and an Apache inside.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 11 December 2008 07:00:53 am Carlos E. R. wrote:
On Thursday, 2008-12-11 at 13:41 +0100, Pavol Rusnak wrote:
I sure hope that advanced bash users (the ones you are probably referring to, not all bash users) are able to add 'unset command_not_found_handle' to their profiles.
I suggest you add that info as a comment to the default profile - same as there is a comment on "fortune".
That would be my favorite solution too. Simple comment: # If you don't need "command_not_found" just uncomment following line # unset command_not_found_handle' I have no problems with speed of command_not_found, and provided info can be useful. ************************************************ rm@linux> time nc The program 'nc' can be found in the following package: * netcat-openbsd [ path: /usr/bin/nc, repository: zypp (repo-oss) ] Try installing with: sudo zypper install netcat-openbsd bash: nc: command not found real 0m0.749s user 0m0.528s sys 0m0.132s ************************************************ Now, just highlight 'zypper install netcat-openbsd' and copy in root shell. Otherwise: rm@linux> nc bash: nc: command not found # go to root shell and # zypper se nc # time zypper se -t package nc Loading repository data... Reading installed packages... S | Name |Summary | Type --+------------------------+----------------------+-------- | ElectricFence | Malloc Debugger | package ......... skip long list that provides nothing ............ real 0m2.527s user 0m1.776s sys 0m0.580s linux-lffm:~ # rpm -q --whatprovides nc no package provides nc and so on. If I don't ask for a netcat I would have to spend some time searching. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 12 of December 2008 05:11:22 Rajko M. wrote:
On Thursday 11 December 2008 07:00:53 am Carlos E. R. wrote:
On Thursday, 2008-12-11 at 13:41 +0100, Pavol Rusnak wrote:
I sure hope that advanced bash users (the ones you are probably referring to, not all bash users) are able to add 'unset command_not_found_handle' to their profiles.
I suggest you add that info as a comment to the default profile - same as there is a comment on "fortune".
That would be my favorite solution too. Simple comment:
# If you don't need "command_not_found" just uncomment following line # unset command_not_found_handle'
Agree, I suppose that documenting how to turn it of is the best solution for geeks (like anicka). I have pushed a new manual page for command-not-found [1]. [1] http://repo.or.cz/w/scout.git?a=commit;h=314d0914d50bd3e6e32fb917f13328a6316... Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 11 Dec 2008, Susanne Oberhauser wrote:
Command not found. If this is not a typo, see make-it-work(1) for help.
And then the make-it-work man page will tell you right away to run "make-it-work commandname' to locate and install the package providing fancytool.
Seasoned shell kiddies will go one back in history, prefix their last command with 'make-it-work ' and have fun...
imho the current solution is solving a problem that doesn't really exist (pretend all software is preinstalled) and creates a new one (lag).
I like the idea. Care to file a request via openFATE, Susanne? Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sunday 01 of February 2009 21:21:33 Gerald Pfeifer wrote:
On Thu, 11 Dec 2008, Susanne Oberhauser wrote:
Command not found. If this is not a typo, see make-it-work(1) for help.
And then the make-it-work man page will tell you right away to run "make-it-work commandname' to locate and install the package providing fancytool.
Seasoned shell kiddies will go one back in history, prefix their last command with 'make-it-work ' and have fun...
Problem is that seasoned shell kiddies don't know about make-it-work command, just because they're kiddies. Better option is change the default behavior of c-n-f handler. On a first run it could print a hint how to activate it, or how to remove it: $ cmd Command 'cmd' not found. To activate the hint type echo "export command_not_found_handle=verbose" >> ~/.bashrc; source ~/.bashrc or disable it by echo "unset commad_not_found_handle" >> ~/.bashrc; source ~/.bashrc $
imho the current solution is solving a problem that doesn't really exist (pretend all software is preinstalled) and creates a new one (lag).
I had many troubles with commands in /usr/sbin, because users responses - it wrote me command not found - even if I told they must use a root. So c-n-f handler warns if command exists and is in /sbin /usr/sbin, which solves those problems. At least this problem is real and exists. Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 2 Feb 2009, Michal Vyskocil wrote:
I had many troubles with commands in /usr/sbin, because users responses - it wrote me command not found - even if I told they must use a root. So c-n-f handler warns if command exists and is in /sbin /usr/sbin, which solves those problems. At least this problem is real and exists.
Good point, this is something I also observed a lot! Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Michal,
I like the /sbin and /usr/sbin lookup.
I've created a feature request for it:
https://features.opensuse.org/305803
I do not agree though to the other suggestion you've made:
Michal Vyskocil
On Sunday 01 of February 2009 21:21:33 Gerald Pfeifer wrote:
On Thu, 11 Dec 2008, Susanne Oberhauser wrote:
Command not found. If this is not a typo, see make-it-work(1) for help.
And then the make-it-work man page will tell you right away to run "make-it-work commandname' to locate and install the package providing fancytool.
Seasoned shell kiddies will go one back in history, prefix their last command with 'make-it-work ' and have fun...
Problem is that seasoned shell kiddies don't know about make-it-work command, just because they're kiddies.
Better option is change the default behavior of c-n-f handler. On a first run it could print a hint how to activate it, or how to remove it:
$ cmd Command 'cmd' not found. To activate the hint type echo "export command_not_found_handle=verbose" >> ~/.bashrc; source ~/.bashrc or disable it by echo "unset commad_not_found_handle" >> ~/.bashrc; source ~/.bashrc $
If I pretend I was a beginner user, this looks very, very cryptic. The 'hint' suggests to make the message go away (to a plain command not found) or to become slow as a dead rat. If I look at a beginner, an average user or an adept, then I'd like the system response to be - short (to please the adept user) - point to full documentation (for the beginner) - give a poointer to immediate remedy (for the average, forgetful user) that's why in the fate request, I've usggested an improved message: Command not found. If this is not a typo, type "man make-it-work" for help. The 'make-it-work' man page will then give guidance to a deep level, while the message is short enough to not annoy anybody. Running 'make-it-work <commandname>' should then just help to install the right package And I agree, the command_not_found_helper should also check /sbin and /usr/sbin and respond with a message like this in case the command is there: "$command" is a privileged command. Try "sudo $command"? S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Susanne Oberhauser wrote:
I like the /sbin and /usr/sbin lookup.
I've created a feature request for it: https://features.opensuse.org/305803
I do not agree though to the other suggestion you've made:
I did the proposed changes and closed the feature as DONE. You can read more at http://stick.gk2.sk/blog/?p=95 -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/2/9 Pavol Rusnak
I did the proposed changes and closed the feature as DONE. You can read more at http://stick.gk2.sk/blog/?p=95
That looks great. I wonder though if this is as clear as can be? Would you mind considering a suggestion as feedback. "Now it prints this info immediately: $ blender If 'blender' is not a typo you can run the following command to lookup the package that contains the binary: command-not-found blender bash: blender: command not found $ ifconfig Absolute path to 'ifconfig' is '/sbin/ifconfig', so it might be intended to be run only by user with superuser privileges (eg. root). bash: ifconfig: command not found " Suggested simpler text $ blender If 'blender' is not a typo you can use command-not-found to lookup the package that contains it, like this : command-not-found blender bash: blender: command not found $ ifconfig 'ifconfig' has path '/sbin/ifconfig', so it may require root privileges should typing /sbin/ifconfig fail to work correctly bash: ifconfig: command not found This seems simpler to understand, and avoids geek speak words like 'binary', without being ambiguous, and gives good hints towards 'best practice'. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Rob OpenSuSE
That looks great. I wonder though if this is as clear as can be? Would you mind considering a suggestion as feedback.
"Now it prints this info immediately:
$ blender If 'blender' is not a typo you can run the following command to lookup the package that contains the binary: command-not-found blender bash: blender: command not found
$ ifconfig Absolute path to 'ifconfig' is '/sbin/ifconfig', so it might be intended to be run only by user with superuser privileges (eg. root). bash: ifconfig: command not found "
Suggested simpler text
$ blender If 'blender' is not a typo you can use command-not-found to lookup the package that contains it, like this : command-not-found blender bash: blender: command not found
$ ifconfig 'ifconfig' has path '/sbin/ifconfig', so it may require root privileges should typing /sbin/ifconfig fail to work correctly bash: ifconfig: command not found
This seems simpler to understand, and avoids geek speak words like 'binary', without being ambiguous, and gives good hints towards 'best practice'.
+1 -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Patrick Shanahan wrote:
This seems simpler to understand, and avoids geek speak words like 'binary', without being ambiguous, and gives good hints towards 'best practice'.
+1
Thanks for the feedback. I just changed wording to be less geeky. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (13)
-
Anicka Bernathova -
anicka＠suse.cz
-
Carlos E. R. -
Gerald Pfeifer -
Josef Reidinger -
Lubos Lunak -
Michal Vyskocil -
Patrick Shanahan -
Pavol Rusnak -
peter nikolic -
Rajko M. -
Rob OpenSuSE -
Susanne Oberhauser