Re: trapped in bash

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 18/12/16 06:30 PM, Bart Schaefer wrote:
> On Dec 19, 12:32am, Daniel Shahaf wrote:
> }
> } I suppose you could write a command_not_found_handler() function that
> } tried to reverse engineer _why_ the command wasn't found - with the
> } obvious limitations, e.g., race conditions between the library's
> } execution and the handler's.
>
> I don't think there can be a race here because the handler won't be
> invoked if the execve() hasn't already failed.
>
> Something like this:
>
> command_not_found_handler () {
>    local attempt="$1"
>    if [[ "$1" != /* && ( -o pathdirs || "$1
> " != */* ) ]]
>    then
>      emulate zsh -c 'attempt=$^path/$1(N[1])'
>    fi
>    if [[ -f $attempt ]]
>    then
>      local hashbang
>      read -u 0 -k 2 hashbang < "$attempt"
>      case "$hashbang" in
>        ('#!') print -u2 -- $1\: bad '#!' interpreter ;;
>        (*) print -u2 failed to load $1 ;;
>      esac
>    else
>      print -u2 -- $1\: no such file in \$PATH
>    fi
>    return 127
> }
Not for me to say, but it seems to me that the simple fact that a file 
exists or does not exist is simple enough to determine in the tradition 
of 'whence' or something like that.  *Then* we run into issues about 
executing it *after* the thing has (obviously) been found.  Sometimes a 
command can't be found because it can't be found, that is, the file 
simply does not exist.  Or is that too simple?  Anyway I sure like the idea.