Re: Insensitive wildcard matching

[Alessandro Vesely]

Hi Eli,

Eli Zaretskii wrote:
> 
> > Date: Mon, 26 Jul 2004 08:08:11 +0200
> > From: Alessandro Vesely <address@hidden>
> >
> > IMHO the question is not much what windows OS would be [non-]conformant to,
> > but rather if it is misleading or not to allow `echo' to be resolved as
> > an internal shell command, but then keep the possibility to issue an `ECHO'
> > command that will instead resolve to a non-shell `echo.exe', if one can be
> > found on the current PATH.
> 
> IMNSHO, Make on Windows should _always_ prefer non-shell echo.exe if
> it can be found.  That's because echo.exe's functionality is a
> superset of what the Windows shell builtin can do, so you lose
> nothing; what you gain is the ability to have Unixy features in
> Makefile's.  (If one wants the shell builtin, one can always say
> something like "cmd.exe /c echo ...".)

But how does one know echo.exe does echoing its arguments rather than
being, say, an echology adventure game? Coherency is not the peculiarity
of Windows boxes. Users that already installed sh.exe probably don't need
such sophistictions anyway...

Yes, the builtin echo is ridicolous. Suffices to say it displays "Echo is off"
instead of a blank line. Advanced users should use printf... :-)

Anyway, I should not have put unrelated changes in the same patch file.
My only excuse is that it is easy to peel that off if not wanted, Or should
I submit different patches? (Only later I noticed that there is patches
area in Savannah.)

> FWIW, the DJGPP (a.k.a. DOS) port of GNU Make works like that, and I
> have yet to hear a single complaint.

As you pointed out a week ago, the DOS port doesn't work under Windows.
(The MS link.exe, at least the version coming with MSVC 5, wants case
sensitive environment variables.)