Bug 432579 - Port command-not-found to Fedora
Summary: Port command-not-found to Fedora
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-13 01:42 UTC by Rahul Sundaram
Modified: 2013-03-13 05:43 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-16 15:54:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dummy patch (2.73 KB, patch)
2008-12-02 10:15 UTC, Richard Hughes
no flags Details | Diff

Description Rahul Sundaram 2008-02-13 01:42:25 UTC
Description of problem:

When particular packages are not found, bash returns command not found. This
utility will help in making more useful suggestions to the end user. 

Additional info:

Originally written for Ubuntu, it is also recently ported to OpenSUSE. 

http://idea.opensuse.org/content/ideas/command-not-found-for-opensuse
https://launchpad.net/ubuntu/+spec/command-not-found-magic

A small bash path adds a handler which relies on some precooked data to return
the appropriate package to install.

Comment 1 Bug Zapper 2008-05-14 05:09:50 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

Comment 2 Bill Nottingham 2008-12-02 04:09:01 UTC
This smells more like a packagekit hook than anything else.

Comment 3 Richard Hughes 2008-12-02 08:26:50 UTC
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.

Comment 4 Richard Hughes 2008-12-02 10:15:27 UTC
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.

Comment 5 Roman Rakus 2008-12-02 15:34:30 UTC
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.

Comment 6 Richard Hughes 2008-12-02 18:01:01 UTC
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...

Comment 7 Roman Rakus 2008-12-04 09:31:04 UTC
Also patch for (t)csh, zsh and all other shells.

Comment 8 Richard Hughes 2008-12-04 10:20:32 UTC
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.

Comment 9 Roman Rakus 2008-12-04 14:26:35 UTC
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.

Comment 10 Roman Rakus 2008-12-04 15:50:49 UTC
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.

Comment 11 Richard Hughes 2008-12-04 18:40:47 UTC
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
}

Comment 12 Richard Hughes 2008-12-05 16:59:14 UTC
I've done the PackageKit bits, and blogged about it here: http://blogs.gnome.org/hughsie/2008/12/05/command-not-found/

Comment 13 Roman Rakus 2008-12-08 11:23:24 UTC
Yes, you can.

Comment 14 Behdad Esfahbod 2008-12-08 12:58:29 UTC
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)?

Comment 15 Pavol Rusnak 2009-02-12 08:22:50 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.