Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)

[Tim Kientzle]

On Jul 4, 2012, at 6:42 PM, Mike Meyer wrote:

> On Wed, 4 Jul 2012 18:03:05 -0700
> Tim Kientzle <tim at kientzle.com> wrote:
>> I'm curious whether the earlier objections were due to
>> misunderstandings about auto-install.  Auto-install would
>> be problematic, but the feature being discussed here does not
>> require installation.  Just better error messages.
> 
> My objection was not due to misunderstanding about auto-install. I
> find the feature annoying - spewing a bunch of crap at me because of a
> typo. It annoys me far more often than it actually helps me, because
> more often than not the "missing command" is a typo, *not* an attempt
> to run a command I don't have. I.e., if I type mmap instead of nmap, I
> get:
> 
> mwm at IPGhosterCrawlerI:~$ mmap
> No command 'mmap' found, did you mean:
> Command 'jmap' from package 'openjdk-6-jdk' (main)
> Command 'jmap' from package 'openjdk-7-jdk' (universe)
> Command 'gmap' from package 'gmap' (multiverse)
> Command 'gmap' from package 'scotch' (universe)
> Command 'tmap' from package 'emboss' (universe)
> Command 'smap' from package 'slurm-llnl' (universe)
> Command 'pmap' from package 'procps' (main)
> Command 'moap' from package 'moap' (universe)
> Command 'umap' from package 'libunicode-map8-perl' (main)
> Command 'map' from package 'sgt-puzzles' (universe)
> Command 'amap' from package 'amap-align' (universe)
> mmap: command not found

I agree this is excessive.

In this case, a better UI might be to separate the typo handling
from the package reference, so that you would see something
like this:

$ mmap
mmap: command not found
Perhaps you meant one of: jmap, gmap, tmap, smap, (8 others)

That way, if you did really mean jmap, you could try again and see

$ jmap
jmap: command not found
  Try installing one of the following packages:
      java/openjdk-6-jdk
      java/openjdk-7-jdk

I agree also about the convenience of having a tool that
can identify the port/package that would install a particular
library (or other file).  I too have run into the situation where
I need a particular library and can't figure out what the package
is called.


> bash and zsh already have command_not_found handlers. I don't really
> object to that functionality to sh and tcsh. Just *don't turn it on by
> default*. I don't think I'd even object to setting those handlers in
> /usr/share/skel.

How about if it's on by default (in the default /etc/cshrc)
but very easy to turn off?

The primary point of such a feature is to help people new
to FreeBSD.  Someone who sits down at a new FreeBSD installation
and wants to run 'nmap' can then get up to speed a lot more quickly,
since they'll be pointed at the right package right away.

> Of course, I might turn around and ask that we add support for command
> correction ala zsh to sh & tcsh via those hooks if they get added.
> 

<grin>

Tim