Bug 432579
| Summary: | Port command-not-found to Fedora | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rahul Sundaram <sundaram> | ||||
| Component: | PackageKit | Assignee: | Richard Hughes <richard> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 9 | CC: | behdad, bnocera, dcantrell, katzj, lmacken, pgraner, posguy99, rhughes, richard, robin.norwood, rrakus, smohan, stick, tim, tuxbrewr, twaugh | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-02-16 15:54:17 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Rahul Sundaram
2008-02-13 01:42:25 UTC
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This smells more like a packagekit hook than anything else. To be honest, I think we can do a lot better then command-not-found. Precooking data is a bad thing to do as soon as it's generate it's out of date. I'll have a look this morning and see what we can do. Created attachment 325350 [details]
dummy patch
This is the sort of thing we would need to add to the bash package (totally untested) -- would you bash guys be okay with this sort of thing? The /etc/bash_command_not_found file and the /usr/libexec/pk-command-not-found can be shipped in PackageKit pretty trivially.
What is it good for? We will handle all commands across all packages? And what packages not available in the Fedora repo? What about commands not found, but the package is installed (not in my PATH env.)? And I can imagine the delay, when you try to find the package in database. I don't know, but I think this is not good idea. When you type "make" as a new user, and it says "command not found". Using PackageKit we can query all the packages in the repo, and offer to install "automake". To do this we could generate a client side cache, just like we do desktop files -- or we could query the file directly without a cache, although that takes about 500ms per lookup. The point is without the bash patch it's not possible using any technology. I agree it's not going to work in all cases, but for the new user "make" case I think it would be pretty useful. We don't even have to install it by default, but we do need the bash patches for functionality to be possible... Also patch for (t)csh, zsh and all other shells. Roman, I don't think that is required, as bash-completion is only available for bash, not all the other shells. We also only enable bash by default on all of our spins. We need to be pro-active on features like this, rather than put quick artificial barriers up. If tcsh wants to add functionality like this (and I don't think it would) then they can add this functionality and then re-use the PackageKit or Debian helper trivially. I'm relying on your expertise here, as I can't pretend I'm a bash guru, or even close to upstream. I do think this feature is important, if nothing else to provide feature parity with Debian and Ubuntu. OK. This will be in next release of bash. But only Chet and God know when it will be :) For now I will use, a bit changed, patch from comment #4. bash-3.2-30.fc11 rawhide built. Bash looks for function named `command_not_found_handler'. Note last word. It's not `handle' but `handler'. It seems to make more sense. Roman, great work, I appreciate it. Can I just drop in a handler to /etc/profile.d? Something like this?
command_not_found_handler () {
pk-command-not-found $1 || return 127
}
I've done the PackageKit bits, and blogged about it here: http://blogs.gnome.org/hughsie/2008/12/05/command-not-found/ Yes, you can. I think the check about login shells should be removed and added to the PackageKit part. Why not propose a package to install even if not-found happens in non-login but tty shell (ie, in a shell-script)? Hi! I'm the guy who is responsible for command-not-found in openSUSE together with Michal Vyskocil. During the development we encountered number of serious bugs in patch for bash - mainly occuring when command_not_found_handler executes another binary (which is mostly the case). Most of the bugs wanishes when command_not_found_handler contains only bash internals (like echo ...). We were not able to fix the patch, but included a series of work-arounds in command_not_found_handler. See http://repo.or.cz/w/scout.git?a=blob;f=handlers/bin/command_not_found_bash for the most recent version of our handler function. Work-arounds solve the following issues: * do not run inside midnight commander (puts executable called from handler to background) * do not run inside a pipe (puts executable called from handler to background) * do not run within a subshell (non-existing-command& could cause bash to loose stdin handle => bash exits) We also test for binaries in /sbin and /usr/sbin before executing the search to save time. Hope that helps. |