I’ve been quietly admiring the Debian BASH command not found functionality for a while. For those unfamiliar with the functionality, it suggests installing packages if you typed a command that is not installed. It also seemed to be pretty helpful suggesting replacements for typos.
When Rahul opened a bug to include this in Fedora, I figured this is just the sort of thing a framework like PackageKit needs to hook into. Roman Rakus put a simple patch in Fedora for bash, and now we’ll try to get it upstream. Then it will work on all distros that support PackageKit.
I spent this afternoon hacking a simple implementation. It’s up to the distro whether it should be installed by default on a base install. It’s also pretty configurable, so if you just want it to launch lshal everytime you type lshla, you can have that. If you want it to ask you before it installs shed to provide /usr/bin/shed, then that’s possible too. The simple configuration file is available here for review.
There’s also a screencast available if you want to see all the hotness.
24 thoughts on “Command not found”
the screencast can’t be reached, 403
Yeah but when are we going to get a squiggly red line under misspellings as we type? Ooh, and a squiggly blue line for syntax mistakes! Hm… but what if people need more help? Perhaps a distro-specific mascot (customizable by the user of course) to offer advice!
I kid I kid. I love the command not found feature. :-) Its just easy to see how some good ideas can be taken way too far.
@gino, fixed, thanks.
In the sample configuration file the default value for “SoftwareSourceSearch” is “true”, but “true” is not in the list of the documented allowed values.
Actually this isn’t so useful when you use tab-completion
@Patrick: Fixed, many thanks.
Hasn’t ZSH had similar functionality for quite a while?
It really isn’t a command.
Also include a description?
Please give credit where credit is due. This is an Ubuntu project initially:
The screencast shows some exceptionally fast PackageKit queries happening. What package manager is running behind the scenes in the screencast? yum?
My experience has been that PackageKit(+yum) is much slower than shown in this screencast. I use a 2.4 GHz quad-core machine, so I don’t think it’ll be because your machine’s faster…
@Rob: This is the yum backend using PackageKit 0.4.0. What version are you using? If it’s less that 0.3.10, then you need to upgrade to get the speed boost.
Michael: actually squiggly lines for typos in the shell don’t seem that bad… It could reduce the press-Enter-oh-PK-says-I-made-a-typo-lets-try-again cycle to oh-I-typed-lshl-and-it-underlines-it-already (this assumes a version of commandNotFound that detects that a line starting with lshl is not likely going to be a valid command).
Even better, how about syntax highlighting for shell commands?
It is hilarious to see Ubuntu trying to preach others about giving credit. Ubuntu is notorious for not doing so but let’s talk about something more important. Did you try to send your bash patches upstream like the Fedora people are doing? How about other things you have modified?
The SingleMatch=run option reminds me of DWIM.
Yes, I’m using PackageKit 0.3.9, which I think is normal for most F10 users :-) I look forward to getting 0.4.0.
This is interesting.
Richard any chance you can spin up 0.4 PackageKit and bash built against F10 for us to test with? With the new python 2.6 change in rawhide I’m a little rawhide gun shy at the moment. This is the sort of feature I would want to beat on in a regular work environment to catch the corner cases and get them filed. I don’t want to have to drag all of python 2.6 into my day to day computer to do that sort of testing.
One thing, would it be possible to extend how this work so if packagekit doesn’t have an updated file cache, the suggestion attempt will just fail over instead of waiting for the network activity to complete to update the cache? I’m sort of concerned about bash sitting there waiting on network activity for multiple seconds. it would make more sense to me if PK’s cache update was fired off in the background bash came back to the prompt telling me what it did.
It was not preaching. I was merely saying that if it is goose, it is good for the gander.
If you want credit, push changes upstream instead of keeping them for yourself. Lead rather than play in your little sandbox and demonstrate how you give credit to others for the work they have done which is 99% of your distribution
One more thing, the phrase you used is often termed as sexist since it translates into what is good for men, is good for women too. You might want to use something better.
This is a bit of a pain on livecds, since it means spinning up the media to read in the python binary for every mistake you make typing. Or maybe I should just learn to type better… either way, it’s usually the first thing I disable when I use an ubuntu livecd.
@Jon: No python involved, all raw C.
Cool! Two other command-line interfaces that would benefit from PackageKit are gdb(archer) and autoconf. gdb should prompt you to pull the relevant -debuginfo packages for the program you’re debugging. And configure scripts should ask if you’d like to install the required -devel packages. Anyway, good to see the command line benefiting from this new infrastructure.
Comments are closed.