From: Erwin W. <wat...@xs...> - 2012-06-29 18:34:05
|
Hi, I want to run msys find.exe in the Command Prompt (cmd.exe) with globbing disabled. 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; but still 'find' expands the arguments in cmd.exe. Do I need to disable it in msys-1.0.dll perhaps? regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Earnie B. <ea...@us...> - 2012-07-02 12:21:12
|
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 |
From: Erwin W. <wat...@xs...> - 2012-07-06 10:51:38
|
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/ |
From: Eli Z. <el...@gn...> - 2012-07-06 11:04:57
|
> Date: Fri, 06 Jul 2012 12:24:45 +0200 > From: Erwin Waterlander <wat...@xs...> > > 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/ |
From: Erwin W. <wat...@xs...> - 2012-07-07 06:59:04
|
Eli Zaretskii schreef, Op 6-7-2012 13:04: >> Date: Fri, 06 Jul 2012 12:24:45 +0200 >> From: Erwin Waterlander<wat...@xs...> >> >> 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/ |
From: Earnie B. <ea...@us...> - 2012-07-06 11:37:27
|
On Fri, Jul 6, 2012 at 7:04 AM, Eli Zaretskii <el...@gn...> wrote: >> Date: Fri, 06 Jul 2012 12:24:45 +0200 >> From: Erwin Waterlander <wat...@xs...> >> >> 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 |
From: Erwin W. <wat...@xs...> - 2012-07-07 07:08:08
|
Earnie Boyd schreef, Op 6-7-2012 13:37: > On Fri, Jul 6, 2012 at 7:04 AM, Eli Zaretskii<el...@gn...> wrote: >>> Date: Fri, 06 Jul 2012 12:24:45 +0200 >>> From: Erwin Waterlander<wat...@xs...> >>> >>> 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/ |
From: Eli Z. <el...@gn...> - 2012-07-07 08:45:23
|
> Date: Sat, 07 Jul 2012 08:58:56 +0200 > From: Erwin Waterlander <wat...@xs...> > > > 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 ;-) |
From: Erwin W. <wat...@xs...> - 2012-07-09 06:56:59
|
Eli Zaretskii schreef, Op 7-7-2012 10:45: >> Date: Sat, 07 Jul 2012 08:58:56 +0200 >> From: Erwin Waterlander<wat...@xs...> >> >>> 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/ |
From: Eli Z. <el...@gn...> - 2012-07-07 08:52:23
|
> Date: Sat, 07 Jul 2012 09:08:00 +0200 > From: Erwin Waterlander <wat...@xs...> > > > 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. |
From: Keith M. <kei...@us...> - 2012-07-07 19:58:12
|
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. |
From: Eli Z. <el...@gn...> - 2012-07-07 20:31:35
|
> Date: Sat, 07 Jul 2012 20:58:02 +0100 > From: Keith Marshall <kei...@us...> > > > 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. |
From: Eli Z. <el...@gn...> - 2012-07-09 16:52:05
|
> Date: Mon, 09 Jul 2012 08:56:44 +0200 > From: Erwin Waterlander <wat...@xs...> > > > 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. |
From: Erwin W. <wat...@xs...> - 2012-07-10 06:31:21
|
Eli Zaretskii schreef, Op 9-7-2012 18:51: >> Date: Mon, 09 Jul 2012 08:56:44 +0200 >> From: Erwin Waterlander<wat...@xs...> >> >>> 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/ |
From: Keith M. <kei...@us...> - 2012-07-09 18:57:02
|
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. |
From: Erwin W. <wat...@xs...> - 2012-07-10 07:12:00
|
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/ |
From: Eli Z. <el...@gn...> - 2012-07-09 20:52:00
|
> Date: Mon, 09 Jul 2012 19:56:53 +0100 > From: Keith Marshall <kei...@us...> > > 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 ;-) |