MinGW - Minimalist GNU for Windows

On Fri, Jun 29, 2012 at 2:34 PM, Erwin Waterlander wrote:
> Hi,
>
> I want to run msys find.exe in the Command Prompt (cmd.exe) with
> globbing disabled.
>

Unsupported but...

> To run msys find in cmd.exe I copied find.exe, msys-1.0.dll,
> msys-iconv2.dll, and msys-intl8.dll to c:/tmp/bin/. And I created a
> directory c:/tmp/etc to get any output. Then in cmd.exe I set PATH to
> c:/tmp/bin;%PATH%
>
> I have rebuild msys-findutils with this added to find.c:
>
> int _CRT_glob = 0;
>

You cannot use windows semantics with a POSIX runtime and expect it to work.

> but still 'find' expands the arguments in cmd.exe.
>
> Do I need to disable it in msys-1.0.dll perhaps?

In the MSYS shell you would use a \* or \? to eliminate the globbing.
In the cmd.exe I didn't think the globbing occurred in the shell but
using \* does the trick for me.

Example:
find . -name \*

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Earnie Boyd schreef, Op 2-7-2012 14:21:
> On Fri, Jun 29, 2012 at 2:34 PM, Erwin Waterlander wrote:
>> Hi,
>>
>> I want to run msys find.exe in the Command Prompt (cmd.exe) with
>> globbing disabled.
>>
> Unsupported but...
>
>> To run msys find in cmd.exe I copied find.exe, msys-1.0.dll,
>> msys-iconv2.dll, and msys-intl8.dll to c:/tmp/bin/. And I created a
>> directory c:/tmp/etc to get any output. Then in cmd.exe I set PATH to
>> c:/tmp/bin;%PATH%
>>
>> I have rebuild msys-findutils with this added to find.c:
>>
>> int _CRT_glob = 0;
>>
> You cannot use windows semantics with a POSIX runtime and expect it to work.
>
>> but still 'find' expands the arguments in cmd.exe.
>>
>> Do I need to disable it in msys-1.0.dll perhaps?
> In the MSYS shell you would use a \* or \? to eliminate the globbing.
> In the cmd.exe I didn't think the globbing occurred in the shell but
> using \* does the trick for me.
>
> Example:
> find . -name \*
>

I do want to use Unix 'find' in cmd.exe (not in bash), because it is 
extremely handy. I don't know any Windows command that can do the same 
as Unix find.  There are also dos2unix/unix2dos users on Windows who ask 
how to convert files recursively in a tree. I don't want to build this 
into dos2unix, because there is 'find'.

There is GnuWin32, but the find command from GnuWin32 is not usable, 
because it always expands arguments.

UnxUtils has also the find command, and this is the only one usable. It 
does not expand wildcards. But UnxUtils is old and unmaintained, and it 
doesn't build with MinGW.

So I was looking for something up-to-date, that can easily be 
maintained. That is why I tried msys find, but then I have the globbing 
problem. I was thinking that the globbing was done by bash and not by 
msys-1.0.dll.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

> Date: Fri, 06 Jul 2012 12:24:45 +0200
> From: Erwin Waterlander <waterlan@...>
> 
> I do want to use Unix 'find' in cmd.exe (not in bash), because it is 
> extremely handy. I don't know any Windows command that can do the same 
> as Unix find.  There are also dos2unix/unix2dos users on Windows who ask 
> how to convert files recursively in a tree. I don't want to build this 
> into dos2unix, because there is 'find'.
> 
> There is GnuWin32, but the find command from GnuWin32 is not usable, 
> because it always expands arguments.
> 
> UnxUtils has also the find command, and this is the only one usable. It 
> does not expand wildcards. But UnxUtils is old and unmaintained, and it 
> doesn't build with MinGW.
> 
> So I was looking for something up-to-date, that can easily be 
> maintained.

Try the one from here:

  http://sourceforge.net/projects/ezwinports/files/

On Fri, Jul 6, 2012 at 7:04 AM, Eli Zaretskii <eliz@...> wrote:
>> Date: Fri, 06 Jul 2012 12:24:45 +0200
>> From: Erwin Waterlander <waterlan@...>
>>
>> I do want to use Unix 'find' in cmd.exe (not in bash), because it is
>> extremely handy. I don't know any Windows command that can do the same
>> as Unix find.  There are also dos2unix/unix2dos users on Windows who ask
>> how to convert files recursively in a tree. I don't want to build this
>> into dos2unix, because there is 'find'.
>>
>> There is GnuWin32, but the find command from GnuWin32 is not usable,
>> because it always expands arguments.
>>
>> UnxUtils has also the find command, and this is the only one usable. It
>> does not expand wildcards. But UnxUtils is old and unmaintained, and it
>> doesn't build with MinGW.
>>
>> So I was looking for something up-to-date, that can easily be
>> maintained.
>
> Try the one from here:
>
>   http://sourceforge.net/projects/ezwinports/files/

The MSYS find works in Windows cmd.exe.  I tried it.  I gave an
example in my previous response.

find . -name \*

You must escape the wildcard character just as you would in bash.
Erwin, if this isn't working for you then please give us an example of
what isn't working.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Eli Zaretskii schreef, Op 6-7-2012 13:04:
>> Date: Fri, 06 Jul 2012 12:24:45 +0200
>> From: Erwin Waterlander<waterlan@...>
>>
>> I do want to use Unix 'find' in cmd.exe (not in bash), because it is
>> extremely handy. I don't know any Windows command that can do the same
>> as Unix find.  There are also dos2unix/unix2dos users on Windows who ask
>> how to convert files recursively in a tree. I don't want to build this
>> into dos2unix, because there is 'find'.
>>
>> There is GnuWin32, but the find command from GnuWin32 is not usable,
>> because it always expands arguments.
>>
>> UnxUtils has also the find command, and this is the only one usable. It
>> does not expand wildcards. But UnxUtils is old and unmaintained, and it
>> doesn't build with MinGW.
>>
>> So I was looking for something up-to-date, that can easily be
>> maintained.
> Try the one from here:
>
>    http://sourceforge.net/projects/ezwinports/files/
>


Hi Eli,

That's an interesting project! Thanks. From your port I can easily build 
a 'find' version with globbing disabled.

Also the ncurses port is interesting, but I still use PDCurses, because 
it supports Unicode quite well. See my wcd project. A good ncursesw port 
would make me switch.

And funny to see the 'man' clone for which I made a 16 bit DOS port 12 
years ago (http://waterlan.home.xs4all.nl/#MAN_ANCHOR).

best regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

Earnie Boyd schreef, Op 6-7-2012 13:37:
> On Fri, Jul 6, 2012 at 7:04 AM, Eli Zaretskii<eliz@...>  wrote:
>>> Date: Fri, 06 Jul 2012 12:24:45 +0200
>>> From: Erwin Waterlander<waterlan@...>
>>>
>>> I do want to use Unix 'find' in cmd.exe (not in bash), because it is
>>> extremely handy. I don't know any Windows command that can do the same
>>> as Unix find.  There are also dos2unix/unix2dos users on Windows who ask
>>> how to convert files recursively in a tree. I don't want to build this
>>> into dos2unix, because there is 'find'.
>>>
>>> There is GnuWin32, but the find command from GnuWin32 is not usable,
>>> because it always expands arguments.
>>>
>>> UnxUtils has also the find command, and this is the only one usable. It
>>> does not expand wildcards. But UnxUtils is old and unmaintained, and it
>>> doesn't build with MinGW.
>>>
>>> So I was looking for something up-to-date, that can easily be
>>> maintained.
>> Try the one from here:
>>
>>    http://sourceforge.net/projects/ezwinports/files/
> The MSYS find works in Windows cmd.exe.  I tried it.  I gave an
> example in my previous response.'
>
> find . -name \*
>
> You must escape the wildcard character just as you would in bash.
> Erwin, if this isn't working for you then please give us an example of
> what isn't working.
>

Hi Earnie,

Okay, with escaping it works. But I think that escaping and quoting is a 
hassle for an average windows user. And for the 'find' command I see no 
use for the globbing. Globbing makes 'find' fail when the argument 
matches files in the current directory. Therefore I want to turn it off 
for the Windows port of find. I continue with Eli's port of findutils.

best regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

> Date: Sat, 07 Jul 2012 08:58:56 +0200
> From: Erwin Waterlander <waterlan@...>
> 
> >    http://sourceforge.net/projects/ezwinports/files/
> >
> 
> That's an interesting project! Thanks. From your port I can easily build 
> a 'find' version with globbing disabled.

The 'find' you get there already does.  Unless I misunderstand what
you mean by "globbing disabled", and why do you need that, please
explain.

The port of 'find' on that page disables globbing in the startup code,
because Windows Vista and later changed the globbing code in
MSVCRT.DLL such that it now globs even wildcards that are quoted.
This, of course, breaks 'find's -name and similar switches (and also a
lot of other GNU programs that accept wildcards in command-line
arguments).

> Also the ncurses port is interesting, but I still use PDCurses, because 
> it supports Unicode quite well. See my wcd project. A good ncursesw port 
> would make me switch.

I didn't port ncurses, I just built (with a few minor gotchas fixed)
the official ncurses sources, which already support MinGW quite well.
I don't know if they improved Unicode support since then (didn't have
time to check), but you should really talk to ncurses developers about
that, and contribute patches if you can.  I agree that lack of Unicode
support is a major drawback.

> And funny to see the 'man' clone for which I made a 16 bit DOS port 12 
> years ago (http://waterlan.home.xs4all.nl/#MAN_ANCHOR).

What can I say? it's a small world ;-)

> Date: Sat, 07 Jul 2012 09:08:00 +0200
> From: Erwin Waterlander <waterlan@...>
> 
> > find . -name \*
> >
> > You must escape the wildcard character just as you would in bash.
> > Erwin, if this isn't working for you then please give us an example of
> > what isn't working.
> >
> 
> Hi Earnie,
> 
> Okay, with escaping it works. But I think that escaping and quoting is a 
> hassle for an average windows user.

?? But you are _supposed_ to quote wildcards where you need 'find' to
get them unexpanded.

> And for the 'find' command I see no use for the globbing.

There are valid use cases when you'd want globbing.  Here's a trivial
example:

  find *.c -exec fgrep FOOBAR "{}" ";"

> Globbing makes 'find' fail when the argument matches files in the
> current directory.

With unquoted wildcards, and in arguments to -name etc., yes.  That's
why you need to quote them.

> I continue with Eli's port of findutils.

Which already disables globbing where it is not needed, but still does
glob in arguments where you'd want that.  E.g., the above trivial
example should work with my port.

On 07/07/12 09:51, quoting Erwin Waterlander, Eli Zaretskii wrote:
>> Okay, with escaping it works. But I think that escaping and quoting
>> is a hassle for an average windows user.

What?  You mean the average Windows user who litters path and file names
with embedded white space, making quoting mandatory?

> ?? But you are _supposed_ to quote wildcards where you need 'find' to
> get them unexpanded.

Exactly so.

>> And for the 'find' command I see no use for the globbing.
> 
> There are valid use cases when you'd want globbing.  Here's a trivial
> example:
> 
>   find *.c -exec fgrep FOOBAR "{}" ";"

Obviously a contrived example, since

   fgrep FOOBAR *.c

should deliver a similar (perhaps more useful) result, with rather more
natural usage.  Interestingly, although it will work, (I checked), in
20+ years of running and administering *nix systems, I don't think I've
ever considered using a globbing pattern which I'd expect to generate a
list of *file* names, (rather than directory path names), for the search
location in a find command.

>> Globbing makes 'find' fail when the argument matches files in the
>> current directory.

As it *should*...

> With unquoted wildcards, and in arguments to -name etc., yes.  That's
> why you need to quote them.
> 
>> I continue with Eli's port of findutils.
> 
> Which already disables globbing where it is not needed, but still does
> glob in arguments where you'd want that.  E.g., the above trivial
> example should work with my port.

Perhaps I'm misunderstanding here: are you saying that this real world
example, (which I might use to clean up a Mercurial tree after doing an
'hg revert', when I finally want to abandon the reverted changes):

   find -name "*.orig" -exec rm {} +

*wouldn't* glob the "*.orig" argument, if I neglected to quote it?  If
so, that seems a rather dangerous precedent to set -- better to keep the
behaviour consistent with *nix, or MSYS bash, IMO.  But perhaps I'm just
reading too much between the lines, and all you really mean is that
you've circumvented the entirely inappropriate globbing *inside* quotes,
(as recent MSVCRT.DLL seems to insist on doing)?  If the latter is
indeed the case, then apologies for the noise; this is definitely the
right thing to do.

-- 
Regards,
Keith.

> Date: Sat, 07 Jul 2012 20:58:02 +0100
> From: Keith Marshall <keithmarshall@...>
> 
> > There are valid use cases when you'd want globbing.  Here's a trivial
> > example:
> > 
> >   find *.c -exec fgrep FOOBAR "{}" ";"
> 
> Obviously a contrived example, since
> 
>    fgrep FOOBAR *.c
> 
> should deliver a similar (perhaps more useful) result, with rather more
> natural usage.

It was just an example.  If you want to have an example where 'find'
is a must, it's easy to produce one.  For example:

  find *.c -exec -anewer foo.o fgrep FOOBAR "{}" ";"

> Interestingly, although it will work, (I checked), in
> 20+ years of running and administering *nix systems, I don't think I've
> ever considered using a globbing pattern which I'd expect to generate a
> list of *file* names, (rather than directory path names), for the search
> location in a find command.

"*.c" could be replaced by a wildcard matching directories.

The point is that unquoted wildcards on 'find's command line are
perfectly legitimate.  I hope we agree on that.

> >> I continue with Eli's port of findutils.
> > 
> > Which already disables globbing where it is not needed, but still does
> > glob in arguments where you'd want that.  E.g., the above trivial
> > example should work with my port.
> 
> Perhaps I'm misunderstanding here: are you saying that this real world
> example, (which I might use to clean up a Mercurial tree after doing an
> 'hg revert', when I finally want to abandon the reverted changes):
> 
>    find -name "*.orig" -exec rm {} +
> 
> *wouldn't* glob the "*.orig" argument, if I neglected to quote it?

Right.

> If so, that seems a rather dangerous precedent to set -- better to
> keep the behaviour consistent with *nix, or MSYS bash, IMO.

It's better than glob quoted argument to -name and such.  I needed to
choose between 2 evils, and I chose the lesser one.  It is a lesser
one because correct usage of 'find' (with quotes) will work even on
Windows Vista and later.  The other possibility would be to break both
correct and incorrect usage, which I think is worse.

> But perhaps I'm just reading too much between the lines, and all you
> really mean is that you've circumvented the entirely inappropriate
> globbing *inside* quotes, (as recent MSVCRT.DLL seems to insist on
> doing)?

I cannot do that without futzing with MinGW startup code, so I asked
you to do that (and you did ;-).  What I did in 'find' is no more than
a stop-gap measure, designed to let people build and use 'find' with
the current MinGW runtime until there's a proper solution in MinGW.

Eli Zaretskii schreef, Op 7-7-2012 10:45:
>> Date: Sat, 07 Jul 2012 08:58:56 +0200
>> From: Erwin Waterlander<waterlan@...>
>>
>>>     http://sourceforge.net/projects/ezwinports/files/
>>>
>> That's an interesting project! Thanks. From your port I can easily build
>> a 'find' version with globbing disabled.
> The 'find' you get there already does.  Unless I misunderstand what
> you mean by "globbing disabled", and why do you need that, please
> explain.
>
> The port of 'find' on that page disables globbing in the startup code,
> because Windows Vista and later changed the globbing code in
> MSVCRT.DLL such that it now globs even wildcards that are quoted.
> This, of course, breaks 'find's -name and similar switches (and also a
> lot of other GNU programs that accept wildcards in command-line
> arguments).
>

Hi,

My main problem is the globbing of the -name argument. I have not tried 
your version yet. I don't have much time now. I will try next week.
At least with the GnuWin32 version the quoting did not work any way. 
Perhaps your version works better. If single or double quoting works 
then it's OK, and I don't need to turn if off. Besides that I would like 
to point people to a find version which is reasonable up-to-date and 
builds with mingw.

My target audience are cmd.exe and PowerShell users who are NOT familiar 
with Unix shells. Therefore I want to keep it as simple as possible. 
This is for running dos2unix on a tree (find . -name *.txt |xargs 
unix2dos). I don't want to build find into dos2unix, because that is a 
bridge too far. Building find into dos2unix goes against the Unix 
principles and it is not needed for all the people who do run dos2unix 
in a Unix shell.

best regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

> Date: Mon, 09 Jul 2012 08:56:44 +0200
> From: Erwin Waterlander <waterlan@...>
> 
> > The port of 'find' on that page disables globbing in the startup code,
> > because Windows Vista and later changed the globbing code in
> > MSVCRT.DLL such that it now globs even wildcards that are quoted.
> > This, of course, breaks 'find's -name and similar switches (and also a
> > lot of other GNU programs that accept wildcards in command-line
> > arguments).
> 
> My main problem is the globbing of the -name argument.

Globbing of arguments to -name is disabled in my port, because
otherwise 'find' would be broken on Windows Vista and later.

> If single or double quoting works then it's OK, and I don't need to
> turn if off.

It's already turned off in arguments to -name (and also -iname, -path,
etc.).  So it will work with or without quotes.  (The latter was what
Keith alluded to as something unexpected -- which it is, I agree.)

> Besides that I would like to point people to a find version which is
> reasonable up-to-date and builds with mingw.

It's version 4.2.30, so it's from 5 years ago.  However, I didn't see
any significant changes in the later versions.  The latest upstream
version is 4.4.2, released in 2009, so it's just marginally newer.

And yes, I built it with MinGW.

On 09/07/12 17:51, Eli Zaretskii wrote:
>> My main problem is the globbing of the -name argument.
> 
> Globbing of arguments to -name is disabled in my port, because
> otherwise 'find' would be broken on Windows Vista and later.
> 
>> If single or double quoting works then it's OK, and I don't need to
>> turn if off.
> 
> It's already turned off in arguments to -name (and also -iname, -path,
> etc.).  So it will work with or without quotes.  (The latter was what
> Keith alluded to as something unexpected -- which it is, I agree.)

It's not just that I think of it as unexpected; I'd also suggest that it
is mildly objectionable, that you encourage a usage which is more than
likely to fail, should a novice user having learnt this as valid syntax
on Windows ever have occasion to try the same on *nix, (or even in the
MSYS shell).

After all, you did emphasise earlier that you are _supposed_ to quote
arguments to -name, etc. if they might be candidates for expansion by
the shell.  I certainly agree that you must _not_ glob them on Windows,
(because of the way in which Vista and later have broken globbing), but
you did also say that your port should work equally well whether you
quote these arguments, or not, so for consistency with the original *nix
syntax, would it not be better to insist on them being quoted?

At the end of the day, this discussion is purely philosophical; it's
your port, and you're free to implement it as you think best.  However,
from my POV, departure from original native *nix _syntax_, (as opposed
to _semantics_), is perhaps *not* a good thing to encourage.

-- 
Regards,
Keith.

> Date: Mon, 09 Jul 2012 19:56:53 +0100
> From: Keith Marshall <keithmarshall@...>
> 
> After all, you did emphasise earlier that you are _supposed_ to quote
> arguments to -name, etc. if they might be candidates for expansion by
> the shell.  I certainly agree that you must _not_ glob them on Windows,
> (because of the way in which Vista and later have broken globbing), but
> you did also say that your port should work equally well whether you
> quote these arguments, or not, so for consistency with the original *nix
> syntax, would it not be better to insist on them being quoted?

Yes, it would be better.  But as long as I'm doing everything in
'main' and its subroutines, I can only access the original command
line via GetCommandLine, since the quotes are stripped before they get
to argv[].  And then I'd need to manually parse the original command
line to detect whether arguments that needed to be quoted actually
were.

Perhaps, one rainy day I'll do that, if a MinGW runtime with its own
globbing won't beat me to it ;-)

Eli Zaretskii schreef, Op 9-7-2012 18:51:
>> Date: Mon, 09 Jul 2012 08:56:44 +0200
>> From: Erwin Waterlander<waterlan@...>
>>
>>> The port of 'find' on that page disables globbing in the startup code,
>>> because Windows Vista and later changed the globbing code in
>>> MSVCRT.DLL such that it now globs even wildcards that are quoted.
>>> This, of course, breaks 'find's -name and similar switches (and also a
>>> lot of other GNU programs that accept wildcards in command-line
>>> arguments).
>> My main problem is the globbing of the -name argument.
> Globbing of arguments to -name is disabled in my port, because
> otherwise 'find' would be broken on Windows Vista and later.
>
>> If single or double quoting works then it's OK, and I don't need to
>> turn if off.
> It's already turned off in arguments to -name (and also -iname, -path,
> etc.).  So it will work with or without quotes.  (The latter was what
> Keith alluded to as something unexpected -- which it is, I agree.)

Sounds like your version is exactly what I'm looking for. :)

> It's version 4.2.30, so it's from 5 years ago. However, I didn't see 
> any significant changes in the later versions. The latest upstream 
> version is 4.4.2, released in 2009, so it's just marginally newer.

That is good enough.

>
> And yes, I built it with MinGW.
>

Perfect.

Perhaps I try to build a 64-bit version, because I offer 32 and 64 bit 
dos2unix binaries. The 32 vs 64 bit download ratio from my page is now 
about 50/50.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

Keith Marshall schreef, Op 9-7-2012 20:56:
> After all, you did emphasise earlier that you are_supposed_  to quote
> arguments to -name, etc. if they might be candidates for expansion by
> the shell.  I certainly agree that you must_not_  glob them on Windows,
> (because of the way in which Vista and later have broken globbing), but
> you did also say that your port should work equally well whether you
> quote these arguments, or not, so for consistency with the original *nix
> syntax, would it not be better to insist on them being quoted?
>
> At the end of the day, this discussion is purely philosophical; it's 
> your port, and you're free to implement it as you think best. However, 
> from my POV, departure from original native *nix _syntax_, (as opposed 
> to _semantics_), is perhaps *not* a good thing to encourage. 

I agree with you that the Unix syntax should not be discouraged. On the 
other hand it is convenient if the -name argument works also without 
quotes in cmd.exe for those people who will never use a Unix shell. 
Enforcing Unix shell rules on those people is not something I prefer.

GnuWin32 find does not support quoting at all. The UnxUtils find port 
works only without quotes or with double quotes, not with single quotes. 
Eli's version works without, with double and single quotes. On Unix 
shells you have to use single quotes, or escapes, and double quotes may 
work depending on your shell. So it is a bit of a mess. Not something I 
like to educate people who work in cmd.exe.

It is a pity that cmd.exe doesn't provide something similar as Unix 
find. Perhaps PowerShell does, but I don't know.

best regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/