When using bash shell, a command_not_found_handle is run if the command can’t be found. On my Fedora 28 this caused issues.

Background

I have several linux workstations on my disposal, one of them runs Fedora 28.

What

I recently noticed that if I mistyped a command in a terminal, I would get the usual ‘command not found’ message, but the prompt would not return until I hit CTRL+c:

[askolsam@workstation ~]$ lsl
bash: lsl: command not found
^C

How

Bash tries to run command_not_found_handle function whenever it cannot find the command to run. In more detail, as explained in the bash documentation (emphasis mine):

After a command has been split into words, if it results in a simple command and an optional list of arguments, the following actions are taken.

  1. If the command name contains no slashes, the shell attempts to locate it. If there exists a shell function by that name, that function is invoked as described in Shell Functions.
  2. If the name does not match a function, the shell searches for it in the list of shell builtins. If a match is found, that builtin is invoked.
  3. If the name is neither a shell function nor a builtin, and contains no slashes, Bash searches each element of $PATH for a directory containing an executable file by that name. Bash uses a hash table to remember the full pathnames of executable files to avoid multiple PATH searches (see the description of hash in Bourne Shell Builtins). A full search of the directories in $PATH is performed only if the command is not found in the hash table. If the search is unsuccessful, the shell searches for a defined shell function named command_not_found_handle. If that function exists, it is invoked with the original command and the original command’s arguments as its arguments, and the function’s exit status becomes the exit status of the shell. If that function is not defined, the shell prints an error message and returns an exit status of 127.
  4. If the search is successful, or if the command name contains one or more slashes, the shell executes the named program in a separate execution environment. Argument 0 is set to the name given, and the remaining arguments to the command are set to the arguments supplied, if any.
  5. If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script and the shell executes it as described in Shell Scripts.
  6. If the command was not begun asynchronously, the shell waits for the command to complete and collects its exit status.

Well. The command_not_found_handle is defined in /etc/profile.d/PackageKit.sh and it basically runs /usr/libexec/pk-command-not-found. And for some reason pk-command-not-found doesn’t want to return.

Why

  • strace did not give me any straight answers
  • Someone else in the StackExchange had this same issue.

Lo and behold, I didn’t have the PackageKit-command-not-found package installed:

[askolsam@workstation ~]$ sudo yum list installed | grep -i PackageKit
PackageKit.x86_64                          1.1.10-1.fc28                @updates
PackageKit-command-not-found.x86_64        1.1.10-1.fc28                @updates
PackageKit-glib.x86_64                     1.1.10-1.fc28                @updates
PackageKit-gstreamer-plugin.x86_64         1.1.10-1.fc28                @updates
PackageKit-gtk3-module.x86_64              1.1.10-1.fc28                @updates

[askolsam@workstation ~]$ yum search command-not-found
Last metadata expiration check: 1 day, 3:40:53 ago on Mon 15 Oct 2018 10:46:57 EEST.
========================================= Name Matched: command-not-found ==========================================
PackageKit-command-not-found.x86_64 : Ask the user to install command line programs automatically

And at this point I just decided to run unset command_not_found_handle and resume whatever I was originally doing write a blog post about this issue.

Resources