Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

_path_files prefix handling

There's a general problem with _path_files which we've encountered
before and fixed with specifics (e.g. the fake style), but actually
needs fixing generally.

If I want to complete /some/path/to/a/dir/<here>, then any failed
component in the directory path will stop me completing, even if
the full component /some/path/to/a/dir/ is found and has entirely
standard Unix behaviour.  We encountered this in Cygwin, but it occurs
in ClearCase too:


behaves like an ordinary directory, but there is no radiosched_data.c@@
in the directory list for lc --- even though
[[ -d <stuff>/radiosched_data.c@@ ]] returns true.

This is looking to me increasingly like an intrinsic limitation of the
completion system.  I can see two ways out.

1. At the least we could test [[ -d pathcomponent ]] at each stage and
trust the system to get this right, rather than rely on pathcomponent
appearing in the list of entries in the current directory.  This ought
to be relatively simple, and I think fixes all the problems I know about
--- this test works for all components of /cygdrive/c/Program\ Files
under Cygwin, for example, making half of `fake's properties redundant
(you still need it to be offered the choice, but don't need it for the
system to recognise that the choice is a valid path component).

2. Probably unnecessary now 1. has occurred to me, but a large fraction
of the time with a long path you simply want to complete the last
component.  This could presumably be optimised along the lines of

  if [[ -d ${PREFIX:h} ]] then

as a style, possibly set by default.  Presumably involves more invasive
surgery than the first option, but I'd very much like to see one of the
two implemented.

_path_files is fairly complicated, but I suspect 1. could be done
without more than a modicum of frustration.

Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070

The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
If you received this in error, please contact the sender and 
delete the material from any computer.

Messages sorted by: Reverse Date, Date, Thread, Author