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

RE: Zsh observations

At 19:07 8-7-2001, Andrej Borsenkow wrote:
On Sun, 8 Jul 2001, Michael Schaap wrote:

> If I'm trying to complete an executable in the current directory, e.g.
>          % setu<TAB>
> it will give me neither "setup", nor "setup.exe".  This is logical, because
> the special .exe handling is only for the PATH hash.
> Would you know a workaround for that?

Ehh ... path=($path .)

It completes only commands in path; that is correct and expected.

Do you mean, that under Cygwin local directory is always implicitly in
path (it is in DOS)?

Sorry, I made a mistake in my exaple.  I meant:
        % ./setu<TAB>
Another, less useful, example world be:
        % /usr/local/bin/zs<TAB>

> (Wouldn't it be nice if Cygwin did this foo.exe -> foo handling
> automagically for us?)

What do you mean exactly? Zsh hashes path by calling readdir(). I do *not*
want readdir return foo if real file name is foo.exe. There is nothing
Cygwin can do (at least, I cannot think of anything).

Cygwin already has some handling for exe files.  Try
        % ls -l /bin/ls
        % ls -l /bin/ls*
It would be nice if this were more complete, i.e. if all file handling functions would pretend there is a file "/bin/ls". Then it would be less effort to port individual applications, right?

May be in case of foo.exe we should not hash foo.exe but just foo. That
seems logical.

Perhaps, but that's not what I meant.  And your tip,
zstyle ':completion::complete:-command-:*' ignored-patterns '*.(#i)(exe|dll)'
takes care of that anyway.

 - Michael

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