RE: Zsh observations

[Michael Schaap <cygwin@xxxxxxxxx>]

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