Mail Archives: cygwin/2001/07/08/13:34:23
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/
- Raw text -