Re: [h-e-w] find-dired does not work on emacs24 + win + mingw

[sthfrnth]

Thanks for your digging, Eli.

The test results on my machine are listed below.

May I ask a question by the way first?: In find-dired, what is the advantage of using find's -ls option(which emacs24 does) than invoking ls(as in emacs23)?

For this "find"

http://sourceforge.net/projects/ezwinports/files/findutils-4.2.30-w32-bin.zip/download 

"depends find.exe" shows:

- FIND.EXE

 + ADVAPI32.DLL

 + KERNEL32.DLL

 + MSVCRT.DLL

 + MSVCP60.DLL

    MSVCRT.DLL

The MSVCRT.DLL is located in c:\windows\system32, of version 7.0.7600.16385.

For this "find"

http://unxutils.sourceforge.net/

"depends find.exe" shows:

- FIND.EXE

  + WSOCK32.DLL

  + ADVAPI32.DLL

  + MSVCRT.DLL

  + KERNEL32.DLL

The MSVCRT.DLL is the same. Located in c:\windows\system32, of version 7.0.7600.16385.

The "quote test":

E:\tmp>ls

2  2.c  hello.c  hello.o

E:\tmp>emacs -Q -batch --eval "(princ (directory-files \".\" nil \"?*\\.c\\'\"))

"

(2.c hello.c)

E:\tmp>

There are many files matching the pattern "msvcr*.dll" on my machine. Listed below(those from non-Microsoft apps not listed):

C:\MSOCache\All Users\{90120000-006E-0804-0000-0000000FF1CE}-C\msvcr80.dll

C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\VS Runtime\MSVCR70.DLL

C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\VS Runtime\MSVCR71.DLL

C:\Program Files (x86)\Microsoft Office\Office12\ADDINS\MSVCR71.DLL

C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn\msvcr71.dll

C:\Program Files (x86)\Microsoft SQL Server\90\Setup Bootstrap\BPA\msvcr71.dll

C:\Program Files (x86)\Microsoft SQL Server\90\Setup Bootstrap\msvcr80.dll

C:\Windows\System32\msvcr100.dll

C:\Windows\System32\msvcr100_clr0400.dll

C:\Windows\System32\msvcr71.dll

C:\Windows\System32\msvcrt.dll

C:\Windows\System32\msvcrt20.dll

C:\Windows\System32\msvcrt40.dll

C:\Windows\System32\MSVCRTD.DLL

C:\Windows\SysWOW64\msvcr100.dll

C:\Windows\SysWOW64\msvcr100_clr0400.dll

C:\Windows\SysWOW64\msvcr71.dll

C:\Windows\SysWOW64\msvcrt.dll

C:\Windows\SysWOW64\msvcrt20.dll

C:\Windows\SysWOW64\msvcrt40.dll

C:\Windows\SysWOW64\MSVCRTD.DLL

C:\Windows\winsxs\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_93b21c24844efba7\msvcr80.dll

C:\Windows\winsxs\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_88dce9872fb18caf\msvcr80.dll

C:\Windows\winsxs\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_88df89932faf0bf6\msvcr80.dll

C:\Windows\winsxs\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_none_c905be8887838ff2\msvcr80.dll

C:\Windows\winsxs\amd64_microsoft.vc80.debugcrt_1fc8b3b9a1e18e3b_8.0.50727.42_none_a7c7c85b408f32ea\msvcr80d.dll

C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_08e3747fa83e48bc\msvcr90.dll

C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_08e1a05ba83fe554\msvcr90.dll

C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4940_none_08e4299fa83d7e3c\msvcr90.dll

C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251\msvcr90.dll

C:\Windows\winsxs\amd64_microsoft-windows-msvcrt_31bf3856ad364e35_6.1.7600.16385_none_2d4a27c7b8972454\msvcrt.dll

C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4053_none_d08d7da0442a985d\msvcr80.dll

C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_db5f52fb98cb24ad\msvcr80.dll

C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5\msvcr80.dll

C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fc\msvcr80.dll

C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\msvcr80.dll

C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_none_10b2f55f9bffb8f8\msvcr80.dll

C:\Windows\winsxs\x86_microsoft.vc80.debugcrt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_e4a70117006762dd\msvcr80d.dll

C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.8_none_bcb86ed6ac711f91\msvcr90.dll

C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_none_e163563597edeada\msvcr90.dll

C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\msvcr90.dll

C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\msvcr90.dll

C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4940_none_50916076bcb9a742\msvcr90.dll

C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\msvcr90.dll

C:\Windows\winsxs\x86_microsoft-windows-core_tools_31bf3856ad364e35_6.1.7600.16385_none_0be0764718e4d1ce\msvcrt40.dll

C:\Windows\winsxs\x86_microsoft-windows-msvcrt_31bf3856ad364e35_6.1.7600.16385_none_d12b8c440039b31e\msvcrt.dll

C:\Windows\winsxs\x86_microsoft-windows-msvcrt20_31bf3856ad364e35_6.1.7600.16385_none_edfa3292d2258f2c\msvcrt20.dll

On Sat, Jan 28, 2012 at 4:07 PM, Eli Zaretskii <address@hidden> wrote:

> Date: Sat, 28 Jan 2012 14:12:12 +0800

> From: sthfrnth <address@hidden>
> Cc: address@hidden, address@hidden
>

> The "find.exe" in this package
> http://sourceforge.net/projects/ezwinports/files/findutils-4.2.30-w32-bin.zip/download
>
> produces:

> *
> *
> *C:\emacs\lisp>find . -name *find**
> *find: paths must precede _expression_*
> *Usage: find [-H] [-L] [-P] [path...] [_expression_]*
> *
> *
> *C:\emacs\lisp>find . -name "*find*"*
> *find: paths must precede _expression_*
> *Usage: find [-H] [-L] [-P] [path...] [_expression_]*

This works flawlessly for me, with the same binary.

There are half-confirmed rumors that Microsoft changed their
implementation of how quoted strings are handled when the arguments
passed to a C program are expanded.  You said you were on Windows 7,
so perhaps this is what causes this problem for you.  It is possible
that programs need to be linked in some special way to avoid these
very serious regressions.

To help find a workaround, can you run "depends find.exe" on find.exe
from the package

 http://sourceforge.net/projects/ezwinports/files/findutils-4.2.30-w32-bin.zip/download

and see which version of MSVCRT.DLL is picked up by it?  Also, can you
tell which files matching the pattern "msvcr*.dll" (case-insensitively)
are present on your machine?

If you don't have depends.exe, you should be able to download it from
the Internet:

 http://support.microsoft.com/kb/256872

Can others on this list who have Windows 7 or Vista please see whether
quoted wildcards misbehave on those versions?  One way of doing this
is to type the following command:

 emacs -Q -batch --eval "(princ (directory-files \".\" nil \"?*\\.c\\'\"))"

If quoted arguments work "as I'd expect" (i.e. quotes are removed,
unless escaped by a backslash, in which case the backslash is removed
and the quote stays), then this command should display the list of all
*.c files in the directory where you invoke this command.  (Do it in a
directory where *.c files do exist.)  If quoted arguments don't work,
then the result will probably be the exact replica of the --eval
argument, or maybe some weird error message.

> The "find.exe" in this package
> http://unxutils.sourceforge.net/
> produces:
>
> C:\emacs\lisp>find . -name *find*
> .\cedet\semantic\db-find.el
> .\cedet\semantic\db-find.elc
> .\cedet\semantic\find.el
> .\cedet\semantic\find.elc
> .\cedet\srecode\find.el
> ...
> C:\emacs\lisp>find . -name "*find*"
> .\cedet\semantic\db-find.el
> .\cedet\semantic\db-find.elc
> .\cedet\semantic\find.el
> .\cedet\semantic\find.elc
> .\cedet\srecode\find.el
> ...
>
> I don't know why.
> I think the second "find.exe" is more powerful in my env..

Can you please run "depends find.exe" on this version of find.exe as
well, and see which DLLs it uses?