RE: Zsh observations

RE: Zsh observations

[Andrej Borsenkow]

>
> At 07:59 5-7-2001, Andrej Borsenkow wrote:
> >Zsh relies on system execve to find command. Basically, it does
> >
> >for dir in path
> >   execve dir/cmd
> >
> >until it succeeds. We recently have a brief discussion on
> zsh-workers about
> >it. Irrespectivley if you consider it a bug or feature this was
> around for a
> >very long time. So the above lets suspect problem in Cygwin exec
> - sometimes
> >it fails to execute /a/hello.exe. Can you reliably reproduce it?
>
> Yes, I've figured it out.
> It only happens when "setopt correct" is set, the first instance
> of a file
> in the PATH has a .exe extension, and the second doesn't.  Here's how to
> reproduce it.
>
> I created an executable /tmp/a/dummy.exe which prints "a", and a script
> "/tmp/b/dummy" which prints "b".
>
> Move all zsh initialisation files (/etc/z* and ~/.z*) away, and
> open a new
> zsh window.
>

You do not need it. Just do zsh -f. The only file that will be sourced (if
exists) is /etc/zshenv.

> Now type:
>          % PATH=/usr/bin:/tmp/a:/tmp/b
>          % dummy
>          a
>
> Open a new zsh window, and type:
>          % PATH=/usr/bin:/tmp/a:/tmp/b
>          % setopt correct
>          % dummy
>          b
>
> Conclusion: don't use "setopt correct" under Cygwin. :-(
>

Apply this patch and do it :-) It was lost when gcc stopped setting _WIN32
by default.

Note, that it will make completion list executables twice - as foo and
foo.exe. With new completion you may want to set something like

zstyle ':completion::complete:-command-:*' ignored-patterns
'*.(#i)(exe|dll)'

to prevent *.exe and *.dll from appearing in the list (given, that every
foo.exe is already hashed as foo, it is O.K.; and dll is not executable
anyway - or is it?)

With old completion you may set fignore parameter.

cheers

-andrej

Index: Src/hashtable.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/hashtable.c,v
retrieving revision 1.10
diff -u -r1.10 hashtable.c
--- Src/hashtable.c     2001/05/19 09:22:07     1.10
+++ Src/hashtable.c     2001/07/05 11:27:21
@@ -630,9 +630,9 @@
     Cmdnam cn;
     DIR *dir;
     char *fn;
-#ifdef _WIN32
+#if defined(_WIN32) || defined(__CYGWIN__)
     char *exe;
-#endif
+#endif /* _WIN32 || _CYGWIN__ */

     if (isrelative(*dirp) || !(dir = opendir(unmeta(*dirp))))
        return;
@@ -644,7 +644,7 @@
            cn->u.name = dirp;
            cmdnamtab->addnode(cmdnamtab, ztrdup(fn), cn);
        }
-#ifdef _WIN32
+#if defined(_WIN32) || defined(__CYGWIN__)
        /* Hash foo.exe as foo, since when no real foo exists, foo.exe
           will get executed by DOS automatically.  This quiets
           spurious corrections when CORRECT or CORRECT_ALL is set. */
@@ -660,7 +660,7 @@
                cmdnamtab->addnode(cmdnamtab, ztrdup(fn), cn);
            }
        }
-#endif /* _WIN32 */
+#endif /* _WIN32 || __CYGWIN__ */
     }
     closedir(dir);
 }

RE: Zsh observations

[Michael Schaap]

At 13:33 5-7-2001, Andrej Borsenkow wrote:
>Apply this patch and do it :-) It was lost when gcc stopped setting _WIN32
>by default.

Thanks!  Works great!

I assume this patch will make it into the next release of zsh?

Thanks,

  - Michael

RE: Zsh observations

[Michael Schaap]

Hello Andrej,

At 13:33 5-7-2001, Andrej Borsenkow wrote:
>Apply this patch and do it :-) It was lost when gcc stopped setting _WIN32
>by default.
>
>Note, that it will make completion list executables twice - as foo and
>foo.exe. With new completion you may want to set something like
>
>zstyle ':completion::complete:-command-:*' ignored-patterns
>'*.(#i)(exe|dll)'
>
>to prevent *.exe and *.dll from appearing in the list (given, that every
>foo.exe is already hashed as foo, it is O.K.; and dll is not executable
>anyway - or is it?)

This works very nicely, with one exception.
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?

Thanks,

  - Michael

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

RE: Zsh observations

[Andrej Borsenkow]

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)?


>
> (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).

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

-andrej

RE: Zsh observations

[Michael Schaap]

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

RE: Zsh observations

[Andrej Borsenkow]

>
> Sorry, I made a mistake in my exaple.  I meant:
>          % ./setu<TAB>

(tty1)% ./fTAB
(tty1)% ./foo.exe
(tty1)% ll fo*
-rwxrwxrwx    1 MW1G017  ITS             4 Jul  9 09:40 foo.exe*
(tty1)% chmod -x foo.exe
(tty1)% ./fo
No matches for: `external command', `executable file or directory', `builtin
com
mand', `shell function', `alias', `reserved word', `job', or `parameter'

Are you sure setup.exe has execute permissons?

> Another, less useful, example world be:
>          % /usr/local/bin/zs<TAB>
>

Same question.

The problem is, Cygwin will execute file even if it has no executable bit
set. But zsh relies on it to find out executable file(s).  If you do not use
NTEA Cygwin is using some magic to find out (and return in stat) if file is
executable; but if you use NTEA it completly relies on file modes. I do not
know any easy workaround here.

Zsh just assumes that anything in path is executable, hence it can complete
command in path but the same command by file name. I cannot at the moment
say if it correct or not.

-andrej

RE: Zsh observations

[Michael Schaap]

At 07:49 9-7-2001, Andrej Borsenkow wrote:
> >
> > Sorry, I made a mistake in my exaple.  I meant:
> >          % ./setu<TAB>
>
>(tty1)% ./fTAB
>(tty1)% ./foo.exe
>(tty1)% ll fo*
>-rwxrwxrwx    1 MW1G017  ITS             4 Jul  9 09:40 foo.exe*
>(tty1)% chmod -x foo.exe
>(tty1)% ./fo
>No matches for: `external command', `executable file or directory', `builtin
>com
>mand', `shell function', `alias', `reserved word', `job', or `parameter'
>
>Are you sure setup.exe has execute permissons?

         % ls -l
         total 264
         drwxrwxrwx   32 Administ None         4096 Jun 18 10:36 contrib
         drwxrwxrwx   57 Administ None         8192 Jun  3 19:25 latest
         -rwxrwxrwx    1 Administ None       239616 Jul  6 18:16 setup.exe
         -rw-rw-rw-    1 Administ None        17970 Jul  8 16:53 setup.ini

But remember, I've run
         % zstyle ':completion::complete:-command-:*' ignored-patterns 
'*.(#i)(exe|dll)'
on your advice.
This works fine when running things from the $PATH, after applying your 
patch, but not this way.

I guess I'll just stop ignoring exes.  ("Doctor, it hurts when I do this.")

  - Michael

Re: Zsh observations

[Bart Schaefer]

On Jul 9, 11:31am, Michael Schaap wrote:
}
} But remember, I've run
}          % zstyle ':completion::complete:-command-:*' ignored-patterns \
} '*.(#i)(exe|dll)'
} on your advice.

Hmm, looks like you might want to change that to '*.(#i)(exe|dll|ini).'  In
fact, you could just change it to '*.???'.

Then try adding the _ignored completer somewhere near the end of your
completer zstyle, e.g.

    zstyle ':completion:*' completer _complete _ignored

which will complete the ignored patterns iff there are no other matches.

BTW, if Sven is reading this:  Looking at _complete_debug output, I see that
the ignored-patterns end up repeated twice in the setting of _comp_ignore in
_path_files at line 93.  Shouldn't make any difference, but seems odd.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Zsh observations

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> BTW, if Sven is reading this:  Looking at _complete_debug output, I see that
> the ignored-patterns end up repeated twice in the setting of _comp_ignore in
> _path_files at line 93.  Shouldn't make any difference, but seems odd.

Yes.  That's to be able to add the stuff from $fignore (checked just
before that line) and probably other patterns given with -F to
_path_files directly (not automatically/indirectly from _description).

It could be cleaned up, but doesn't bother me enough to try.

Hm, of course we could just define _comp_ignore with -U.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: Zsh observations

[Andrej Borsenkow]

On Mon, 9 Jul 2001, Michael Schaap wrote:

>
>          % ls -l
>          total 264
>          drwxrwxrwx   32 Administ None         4096 Jun 18 10:36 contrib
>          drwxrwxrwx   57 Administ None         8192 Jun  3 19:25 latest
>          -rwxrwxrwx    1 Administ None       239616 Jul  6 18:16 setup.exe
>          -rw-rw-rw-    1 Administ None        17970 Jul  8 16:53 setup.ini
>
> But remember, I've run
>          % zstyle ':completion::complete:-command-:*' ignored-patterns
> '*.(#i)(exe|dll)'
> on your advice.
> This works fine when running things from the $PATH, after applying your
> patch, but not this way.
>

If you posted the above in your first mail it would no take seven messages
to two lists to find the truth :-) Always try vanilla zsh first (zsh -f;
autoload -U compinit; compinit). If the problem goes away - try to find
what settings are causing the problem. Not that I always do it myself
:-)))

As Bart said, you need _ignored completer. This makes sure that if only
matches from ignored set are found they are suggested as possible matches:

{tty0}:/tmp/tst> ll
total 2
-rwxr-xr-x    1 user     544             1 Jul  9 17:19 foo.exe*
-rw-r--r--    1 user     544             1 Jul  9 17:19 foo.ini
{tty0}:/tmp/tst> zstyle -L
zstyle ':completion:*' matcher-list 'r:|[.,_-]=* r:|=*'
zstyle ':completion::complete:-command-:*' ignored-patterns '*.(#i)exe'
zstyle ':completion:*' completer _complete _ignored
{tty0}:/tmp/tst> ./foTAB
{tty0}:/tmp/tst> ./foo.exe


> I guess I'll just stop ignoring exes.  ("Doctor, it hurts when I do this.")
>

I guess, we really should hash just foo for foo.exe and stop messing with
ignored patterns.

-andrej

RE: Zsh observations

[Michael Schaap]

At 19:30 9-7-2001, Andrej Borsenkow wrote:
>On Mon, 9 Jul 2001, Michael Schaap wrote:
>
> >
> >          % ls -l
> >          total 264
> >          drwxrwxrwx   32 Administ None         4096 Jun 18 10:36 contrib
> >          drwxrwxrwx   57 Administ None         8192 Jun  3 19:25 latest
> >          -rwxrwxrwx    1 Administ None       239616 Jul  6 18:16 setup.exe
> >          -rw-rw-rw-    1 Administ None        17970 Jul  8 16:53 setup.ini
> >
> > But remember, I've run
> >          % zstyle ':completion::complete:-command-:*' ignored-patterns
> > '*.(#i)(exe|dll)'
> > on your advice.
> > This works fine when running things from the $PATH, after applying your
> > patch, but not this way.
> >
>
>If you posted the above in your first mail it would no take seven messages
>to two lists to find the truth :-)

But I did!  Sort of...  (I quoted you giving the zstyle example.  And, of 
course, I forgot the "./" in my example.  ;-) )

>  Always try vanilla zsh first (zsh -f;
>autoload -U compinit; compinit). If the problem goes away - try to find
>what settings are causing the problem. Not that I always do it myself
>:-)))
>
>As Bart said, you need _ignored completer. This makes sure that if only
>matches from ignored set are found they are suggested as possible matches:
>
>{tty0}:/tmp/tst> ll
>total 2
>-rwxr-xr-x    1 user     544             1 Jul  9 17:19 foo.exe*
>-rw-r--r--    1 user     544             1 Jul  9 17:19 foo.ini
>{tty0}:/tmp/tst> zstyle -L
>zstyle ':completion:*' matcher-list 'r:|[.,_-]=* r:|=*'
>zstyle ':completion::complete:-command-:*' ignored-patterns '*.(#i)exe'
>zstyle ':completion:*' completer _complete _ignored
>{tty0}:/tmp/tst> ./foTAB
>{tty0}:/tmp/tst> ./foo.exe

Thanks.  This does the trick.



> > I guess I'll just stop ignoring exes.  ("Doctor, it hurts when I do this.")
> >
>
>I guess, we really should hash just foo for foo.exe and stop messing with
>ignored patterns.

Perhaps that would be the best solution.  Except that then - just as before 
your patch - "setopt correct" will misbehave when you run a command in the 
$PATH without ".exe".
I guess there's no perfect solution for this.

Thanks for your help,

  - Michael (who's now a real zsh convert)