Re: ls.exe */*

> grep.exe or ls.exe etc from  mingw and djgpp (though it is not very
> stable for the binary from mingw if running from msdos shell.)

MS-DOS shell == 16-bit, single user, single tasking system; last ever
version published (in 1994), IIRC, was MS-DOS-6.22.  If you are really
using an MS-DOS shell, you cannot run *any* program from MinGW, because
they all require MS-Win32.  If, OTOH, what you really mean is a Win32
cmd shell...

> It is nice to know that it works for those binaries without cygwin.

Ah, but the "MinGW" binaries to which you refer are actually *MSYS*
binaries, and MSYS is a light-weight derivative of an early version of
Cygwin, so in reality you *are* using Cygwin, although you may not
have realised it.

You should also be aware that MSYS binaries are *not* intended to be
invoked from the cmd.exe shell.  They should be used from the Bourne
shell, which MSYS itself provides.  If you take a fish out of water,
can it still swim?  While you may achieve some limited success when
misusing MSYS tools in this unsupported manner, please don't complain
that they don't work reliably; it is your expectations, and method of
use, which are at fault.

> so you think grep.exe from mingw used msvrt-library to compile?

No, it does not.  Nor does the ls.exe you also mentioned.  As MSYS
programs, they are linked against msys-1.0.dll, (which is a derivative
of an old Cygwin implementation of newlib), instead of MSVCRT.  As a
consequence, they inherit Cygwin's command line parsing capabilities,
which deliver the full gamut of POSIX pattern matches; MS-Windows'
standard pattern matching capabilities, (as available to most native
MS-Windows programs, such as the GnuWin32 suite, and including those
compiled by MinGW -- MSYS programs are *not* built using this), are
rather mediocre in comparison.

--

Regards,
Keith.
------------------------------------------------------------------------------