Re: feature request: file_not_found_handle()
On Mon, Aug 19, 2013 at 08:02:39PM -0700, Linda Walsh wrote: > 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. There are several reasons. 1) PATH is used by the kernel (exec family) to determine how commands are executed. The way PATH is used by the kernel is not likely to change. Having the shell treat it differently would lead to confusion. 2) PATH is important for security. If you type ./foo then you want to run a command in the current directory, or fail. You do NOT want to run /usr/bin/./foo in the event that foo does not exist in the current working directory. If you wanted that behavior, you would have added . to your PATH and typed foo without a prefix. 3) PATH as used by the shell has decades of history behind it. Long-time shell users know how it works, and don't expect it to suddenly start working differently. This is similar to point 1.
Re: feature request: file_not_found_handle()
You are badly using features of bash. Write a script which will do
things for you, or use any other language/shell.
Please, accept this response as a suggestion.
command_not_found_handle is designed to do other things than you are
expecting.
RR
On 08/19/2013 10:29 PM, Andreas Gregor Frank wrote:
Hi Chet,
sorry, i thought you talk about the bash code.
I didn't want to show my own usecase but now i have to ;-):
I have a File class and can construct a File "object" for example:
File anObjectName /etc/passwd
and then i can do
e.g. anObjectName.getInode (this already works with
command_not_found_handle() )
But if i do a:
File /etc/passwd /etc/passwd
and then
/etc/passwd.getInode (i think it would be nice if the normal files in a
filesystem could be treated like objects)
then there is nothing that triggers the command_not_found_handle() to split
"object" and method...
So at the moment slashes are forbidden in object names in my fun project.
Now you know why your bash example for ckexec() isn't a solution for me.
bye
Andreas
2013/8/19 Chet Ramey
On 8/19/13 6:57 AM, Andreas Gregor Frank wrote:
Hi Chet,
I have no idea if there is "enough" demand, but i think there will be
some
ideas to use this feature...
I still think it is a question of consistency to be able to handle a "No
such file or directory event", if i can do this with a "command not found
event" (independent of the command_not_found_handle history).
You say you can easily test whether or not if the file in the pathname
exists.
That is not what I said. I said that you, the script writer, can check
whether or not a filename containing a slash is executable before
attempting to execute it. Maybe a function something like this (untested):
ckexec()
{
case "$1" in
*/*);;
*) "$@" ; return $? ;;
esac
if [ -x "$1" ]; then
"$@"
else
other-prog "$@"
fi
}
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
Re: feature request: file_not_found_handle()
On Tue, Aug 20, 2013 at 05:48:12PM +0300, Aharon Robbins wrote: > In article you write: > >1) PATH is used by the kernel (exec family) to determine how commands are > > executed. The way PATH is used by the kernel is not likely to change. > > Having the shell treat it differently would lead to confusion. > > Actually, PATH searching is implemented in the C library and always > has been; there is only one real system call. The confusion likely arises > from the traditional practice of documenting all the exec calls on the > same manpage. Oh, really? That's very misleading and confusing. HP-UX 10.20 exec(2) says: The exec*() system calls, in all their forms, ... So that's a complete lie, I guess. (And they do appear to be defined in /lib/libc.a if I'm reading the output of nm correctly.)
Re: feature request: file_not_found_handle()
On 8/20/13 11:02 AM, Greg Wooledge wrote: > On Tue, Aug 20, 2013 at 05:48:12PM +0300, Aharon Robbins wrote: >> In article you write: >>> 1) PATH is used by the kernel (exec family) to determine how commands are >>> executed. The way PATH is used by the kernel is not likely to change. >>> Having the shell treat it differently would lead to confusion. >> >> Actually, PATH searching is implemented in the C library and always >> has been; there is only one real system call. The confusion likely arises >> from the traditional practice of documenting all the exec calls on the >> same manpage. > > Oh, really? That's very misleading and confusing. It depends; most people don't really need to know the difference. But yes, there is traditionally only execve(2) and everything else is built on top of it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: feature request: file_not_found_handle()
Roman Rakus wrote: You are badly using features of bash. Write a script which will do things for you, or use any other language/shell. --- Why? Please, accept this response as a suggestion. --- Seems to be a bit provincial. command_not_found_handle is designed to do other things than you are expecting. --- If it wasn't for things doing what we don't expect, many things wouldn't be around (aspirin, popcorn, digitalis, Rogain, & tons more... most things are found by NOT using them they way you are directed to use them). Application of imagination and inventiveness...not that I haven't wondered about the usefulness of some of the things I've come with... BUT some are and many I won't know until I try. Saying someone is not using a tool according to "xxyz"... is akin to a religious accusation of heresy or blasphemy... At that point, people just need to realize that some people can't think outside properly sized boxes...
