Subject: RE: Zsh observations
From: Michael Schaap <[email-masked]>
To: Andrej Borsenkow <[email-masked]>
Cc: <[email-masked]>, ZSH Workers Mailing List <[email-masked]>
Date: Sun, 08 Jul 2001 19:30:42 +0200

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/