Re: feature request: file_not_found_handle()

[Linda Walsh]

Ken Irving wrote:
> On Sun, Aug 18, 2013 at 06:30:47PM -0700, Linda Walsh wrote:
> > 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.
> > ---
> >
> >         How does "lib/font/fontname.ttf" indicate an absolute path?
>
> It's not a question of absolute or relative in that sense, but just
> whether it looks like a path of any sort due to the slash.   The context
> is for the first entry on a command line, and there's no point in
> searching PATH if the value has a slash.  Absolute or relative path makes
> no difference.  I suppose you could say that it's abolutely a path...
---
        Yes, I see what you mean.  I guess I'm not real certain
as to why, if "CDPATH=~/Documents", and I type "cd Pictures/family"
and end up in ~/Documents/Pictures/family, then PATH shouldn't work
the same way.

I typed in a path -- so why should "CDPATH be smart", and do what I
mean, command execution should not?



> It might sound similar but I don't think there's much relation between
> this case, where we are dealing with the command to be executed, and the
> source command and how it handles its arguments.
----

Sorta, but given the above CDPATH setup, I typed in
Pictures/family as a command and I still ended up in the CDPATH relative
dir for ~/Documents/Pictures/family.

So while one can "say" PATH doesn't work that way, and be right, the question
about what is more friendly or convenient may not be the same answer.

Certainly, if it has "/" in it, it should search the current directory
first, and if no slash, then do a path search first possibly followed by
a curdir search (I think posix specifies the path search occurs first, but
leaves the option to search curdir after that undefined/open).


> We want the attempted command, e.g., lib/font/fontname.ttf, once it fails
> bash's attempts to execute it, to be passed to an alternative shell so it
> can have a go.  In my system the handler would try to resolve 
> lib/font/fontname as an object and ttf as a method, or maybe 
> lib/font/fontname.ttf as the object and 'default' as the method.

----

what would be *creative*, is the ability to place a function in the PATH.
When bash did a path search, it would check if it is a plain path or if
a function -- if function, call it with the filename as an arg...

But that just sounds too powerful an option to allow in a shell..