[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature request: file_not_found_handle()

From: Linda Walsh
Subject: Re: feature request: file_not_found_handle()
Date: Mon, 19 Aug 2013 20:02:39 -0700
User-agent: Thunderbird

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:

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..

reply via email to

[Prev in Thread] Current Thread [Next in Thread]