[lucid] command-not-found can't be removed properly using apt

[bcrowell]

Binary package hint: command-not-found

When I was running karmic, I did an apt-get remove command-not-found, and that worked fine. However, when I upgraded to lucid, I started getting the following:

$ thereisnocommandwiththisname
/usr/bin/python: can't find '__main__.py' in '/usr/share/command-not-found'

I do not actually have the command-not-found package installed:

# apt-get remove command-not-found
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package command-not-found is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

So removing the package doesn't fix anything. Even though the package is deselected, I have some of the package's files sitting around:

 $ ls /usr/share/command-not-found/
data priority.txt programs.d

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: command-not-found (not installed)
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Sun Apr 11 15:28:10 2010
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: command-not-found

[bcrowell (launchpadcrowell07)]

Here is a tarball of /var/log/dist-upgrade , in case that is helpful.

[bcrowell (launchpadcrowell07)]

I've changed the title to "command-not-found can't be removed properly using apt," after realizing that this isn't just an issue with upgrading after removing the package. Actually it appears that on any system running lucid, doing an "apt-get remove command-not-found" leaves the shell in the broken state described above.

[Zygmunt Krynicki (zyga)]

Confirmed

Actually this is a bash bug. See /etc/bash.bashrc

# if the command-not-found package is installed, use it
if [ -x /usr/lib/command-not-found -o -x /usr/share/command-not-found ]; then
 function command_not_found_handle {
         # check because c-n-f could've been removed in the meantime
                if [ -x /usr/lib/command-not-found ]; then
     /usr/bin/python /usr/lib/command-not-found -- $1
                   return $?
                elif [ -x /usr/share/command-not-found ]; then
     /usr/bin/python /usr/share/command-not-found -- $1
                   return $?
  else
     return 127
  fi
 }
fi

The second elif case is broken, the directory _still_ exists because command-not-found-data puts some stuff inside. I don't know why the second check exists as the program itself lives in /usr/lib.

[Zygmunt Krynicki (zyga)]

I pushed a fix in my branch, it's linked to this bug

[David Leon (fongsled)]

As a workaround, just remove command-not-found-data and things work fine.

For some reason it's marked as installed manually so it's not removed when you remove command-not-found.

[bcrowell (launchpadcrowell07)]

Thanks, David Leon, for the info. Zygmunt Krynicki, does the patch described in #4 fix this, or does something else need to be done to fix this bug?

[Anders Kaseorg (andersk)]

Only half of bug 561155 was a duplicate of this. I repurposed that bug for the other half (if both command-not-found and command-not-found-data are uninstalled, but a shell remains open, bad commands show no errors at all) and unmarked it as duplicate.

[Thangalin (thangalin-deactivatedaccount)]

After removing "command-not-found-data":

$ asdf
$ asdfqweri83214987
$ zxcv0987asdf0987324
$ d0987xzcv0987safd0987fdsa
$ kjfdsajfdsa;

This should revert to its former behaviour that says, plainly and simply, "Command not found", rather than nothing.

[bcrowell (launchpadcrowell07)]

Interesting info, Thangalin -- thanks for posting that!

So I guess the way I would state the problem now is that if you do an apt-get remove command-not-found, without removing command-not-found-data, you put your system in a state where its behavior is broken. I don't understand why these would even be separate packages, since having one installed without the other doesn't make sense.

[Chris E (cbz)]

If a directory isn't altered, then apt-get purge should remove it. As it is, /usr/share/command-not-found is left around even after an uninstall and a subsequent purge.

[Anders Kaseorg (andersk)]

Fixed in precise.

bash (4.2-2) unstable; urgency=low

  * Fix command-not-found location. Closes: #529313.
  * Print a replacement error message if command-not-found was removed
    after bashrc was loaded. Closes: #631023. LP: #561155.
  * skel.bashrc: Document and prepare enabling the globstar feature (Fabian
    Greffrath). Closes: #627926.
  * Apply upstream patches 021 - 024.

 -- Matthias Klose <email address hidden> Fri, 30 Mar 2012 19:20:04 +0200