PATCH: avoid hashing command names twice on Cygwin

PATCH: avoid hashing command names twice on Cygwin

[Andrej Borsenkow]

Under Cygwin every foo.exe was hashed twice - as foo and foo.exe.

Actually, the code was funny. It contained one block that was executed
unconditionally and exactly the same later under condition.

-andrej

Have a nice DOS!
B >>

Index: Src/hashtable.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/hashtable.c,v
retrieving revision 1.8
diff -u -r1.8 hashtable.c
--- Src/hashtable.c     2001/01/16 13:44:20     1.8
+++ Src/hashtable.c     2001/01/26 13:21:33
@@ -638,29 +638,25 @@
        return;

     while ((fn = zreaddir(dir, 1))) {
+#if defined(_WIN32) || defined(__CYGWIN__)
+       /*
+        * Hash foo.exe as foo, since when no real foo exists, foo.exe
+        * will get executed by DOS and Cygwin automatically.  This quiets
+        * spurious corrections when CORRECT or CORRECT_ALL is set.
+        */
+       if ((exe = strrchr(fn, '.')) &&
+           (exe[1] == 'E' || exe[1] == 'e') &&
+           (exe[2] == 'X' || exe[2] == 'x') &&
+           (exe[3] == 'E' || exe[3] == 'e') && exe[4] == 0)
+           *exe = 0;
+#endif /* _WIN32 || __CYGWIN__ */
        if (!cmdnamtab->getnode(cmdnamtab, fn)) {
            cn = (Cmdnam) zcalloc(sizeof *cn);
            cn->flags = 0;
            cn->u.name = dirp;
            cmdnamtab->addnode(cmdnamtab, ztrdup(fn), cn);
-       }
-#ifdef _WIN32
-       /* 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. */
-       if ((exe = strrchr(fn, '.')) &&
-           (exe[1] == 'E' || exe[1] == 'e') &&
-           (exe[2] == 'X' || exe[2] == 'x') &&
-           (exe[3] == 'E' || exe[3] == 'e') && exe[4] == 0) {
-           *exe = 0;
-           if (!cmdnamtab->getnode(cmdnamtab, fn)) {
-               cn = (Cmdnam) zcalloc(sizeof *cn);
-               cn->flags = 0;
-               cn->u.name = dirp;
-               cmdnamtab->addnode(cmdnamtab, ztrdup(fn), cn);
-           }
        }
-#endif /* _WIN32 */
+
     }
     closedir(dir);
 }

RE: PATCH: avoid hashing command names twice on Cygwin

[Andrej Borsenkow]

>
> Under Cygwin every foo.exe was hashed twice - as foo and foo.exe.
>
> Actually, the code was funny. It contained one block that was executed
> unconditionally and exactly the same later under condition.
>

Hmm ... I believe, this was intentional. But, under Cygwin, foo.exe *is* foo -
stat(foo) returns the same as stat(foo.exe) if foo does not exist. Also, IIRC
_WIN32 was removed from current development version of Cygwin, so the above
would be resolved in favour of foo.exe instead of foo.

We could be more intellegent and test if stat(foo) != stat(foo.exe) to decide
if we should add both. Is it worth troubles?

OTOH it is just command table; for all purposes hashing foo is the same as
hashing foo.exe except very rare cases when both exist.

Comments?

-andrej

Re: PATCH: avoid hashing command names twice on Cygwin

[Peter Stephenson]

> We could be more intellegent and test if stat(foo) != stat(foo.exe) to decide
> if we should add both. Is it worth troubles?
> 
> OTOH it is just command table; for all purposes hashing foo is the same as
> hashing foo.exe except very rare cases when both exist.

It will be confusing if completion doesn't recognise foo.exe as an
executable under its full name.  Hashing both may not be necessary, but it
should preferably be stored and retrieved in such way that both are used
whenever an executable is being searched for.

A natural extension for DOS- and Windows-like environments which could even
be an option on other systems (you wouldn't want it turned on by default)
would be to do what 4DOS used to and take a list of executable suffixes and
interpreters, which could be taken from an array (ordinary so as to specify
precedence), e.g. 

zexecsufixes=(com: exe: pl:'/c/Programe Files/perl/perl.exe' zsh:zsh sh:bash)

where an empty string specifies that the file is already in an executable
format. That suggests that the programme would be stored under it's full
name, or at least with a suitable flag, but returned for completion both as
that and the basename.  But that's a lot of work.  (You could extend it to
shell functions, builtins etc., but that would probably just be asking for 
confusion.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070