Re: feature request: file_not_found_handle()

[Ken Irving]

On Sun, Aug 18, 2013 at 02:35:49PM -0400, Chet Ramey wrote:
> On 8/14/13 7:44 AM, Andreas Gregor Frank wrote:
> > Hi,
> > 
> > i think a file_not_found_handle() or a modified command_not_found_handle(),
> > that does not need an unsuccessful PATH search to be triggered, would be
> > useful and consistent.
> 
> The original rationale for command_not_found_handle is that there was no
> other way to determine whether a command could be found with a PATH search.
> (well, no easy way).
> 
> A PATH search is suppressed when the command to be executed contains a
> slash: the presence of a slash indicates an absolute pathname that is
> directly passed to exec().  Since there's no search done, you know exactly
> which pathname you're attempting to execute, and you can easily test
> whether or not it exists and is executable.
> 
> Is there enough demand to make this feature addition worthwhile?

I guess there are two people that would like to see it, so not exactly a
groundswell of demand.  As a user of bash, there's zero cost on my part
for adding the feature, and real value in having it available.

The alternative is, as now, not being able to use tab-completion easily
to reach an object, or having to edit the slashes out of the command,
so really just more typing.

A simple workaround is to tab-complete to cd into an object
(directory), at which point method calls are local, no slashes, and the
command-not-found hook is fired.

Thanks for considering it at least!

Ken