Re: AUTO_CD (-J) with CDPATH problems

Re: AUTO_CD (-J) with CDPATH problems

[Peter Stephenson]

heiko_elger@arburg.com wrote:
> I have problems using the "AUTO_CD" option with zsh.
> 
> 0:~/jobs> prom          --> is expanded to cd ~/prom
> 0:~/prom> 
> 
> But over the day the same command produces the following error:
> 
> 0:~/jobs> prom
> zsh: the file access permission do not allow the specified action.: prom
> 
> But my access prmissions are still the same
> 0:~> ls -ld prom
> drwxr-xr-x    9 ente59   staff 3584 Sep 28 7:29 prom

The problem arises if the command name `prom' is hashed, i.e. in zsh's
internal tables of where commands are to be found.  For some reason,
this will happen even to subdirectories of a directory of $path ---
the whole of a directory in $path, not just commands, are added to the
command hash table.  So if ~ is in $path, prom is hashed as a command;
then instead of assuming a cd, the shell tries to execute it, but
can't, because it isn't a command.

(The reason it doesn't happen straight away is simply that the
directory doesn't get hashed until the shell needs to look for a
command there.)

I know the same feature has been causing trouble with completion for
some time, but this seems to be the last straw.  I presume hashdir()
does not check individual files for speed.  I could instead write a
function isreallycommand() to test permissions and add it in strategic
places in execcmd() and the completion code.  However, doing it in the
completion code is potentially very slow as well --- in the worse case
it may have to stat() every single hashed command.  I could alleviate
this by getting isreallycommand() to throw out the duff entries and
add a flag for the others (the command may have been moved, of course,
but that's what rehash is for).  However, did anybody ever check how
much slower it was to stat() the entire directory when adding it to
the command hash table?

I can make a minimal patch just for AUTO_CD when the single
stat()/access() is cheap, of course (in fact I've got one), but I'd
prefer to attack the root cause if possible.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 50 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy

Re: AUTO_CD (-J) with CDPATH problems

[Bart Schaefer]

On Sep 28, 11:02am, Peter Stephenson wrote:
} Subject: Re: AUTO_CD (-J) with CDPATH problems
}
} The problem arises if the command name `prom' is hashed, i.e. in zsh's
} internal tables of where commands are to be found.  For some reason,
} this will happen even to subdirectories of a directory of $path ---
} the whole of a directory in $path, not just commands, are added to the
} command hash table.  [...]
} 
} I know the same feature has been causing trouble with completion for
} some time, but this seems to be the last straw.

This is even more annoying in the NT port of zsh, because of course the
DLLs and data files and whatnot all live in the same directories as the
associated executables, so you end up with a -huge- hash table stuffed
with useless junk.  (Unfortunately, a stat()-based fix is of limited
usefulness in that case, because executability is generally a property
of the filename extension only.)

} [...] did anybody ever check how
} much slower it was to stat() the entire directory when adding it to
} the command hash table?

It probably depends on whether some elements of the path are on NFS
servers, and various other local details.  I think it's best left alone,
or made an option (urk).

} I can make a minimal patch just for AUTO_CD when the single
} stat()/access() is cheap, of course (in fact I've got one), but I'd
} prefer to attack the root cause if possible.

There are a few possible approaches short of examining every file in
$path at hashing time.  One would be to examine only files for which
there is an equivalent name in $cdpath or later in $path, i.e., only
stat() when disambiguation is necessary.  Combined with the patch you
just described, that would also catch cases where a subdirectory was
added to a directory in $cdpath after hashing.  (Also, I'd avoid
putting in the command hash table anything that was already in the
named directory hash table, or that was directly included in $path or
$cdpath.)

Except for the above and stray non-commands showing up in completions,
are there other cases where junk in the command hash causes problems?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com