From: Eli Z. <el...@gn...> - 2011-12-25 09:52:37
|
The MSYS Bash and the associated MSYS tools work well for configuring and building MinGW ports (thanks!), but I bumped into an issue when running the resulting executables from the MSYS Bash. I know that doing so is asking for trouble, but it is hard to avoid when running test suites that are part of the packages you just built. A case in point is GNU Grep 2.10: running its test suite after building the MinGW port fails two test (bre and ere) due to a conflict with globbing command lines between Bash and the grep.exe executable just built. The problem is that MinGW executables glob the command line in their startup code, and so commands like this: echo '*' | grep '*' fail. This fails because grep.exe gets a literal "*" (without quotes), and globs it in its startup code, which is not what the test wants. Disabling globbing in the MSYS shell completely for the duration of the test run is not a good idea, because other shell scripts may fail due to that. What tricks people use in these cases? (I eventually hacked the test scripts to disable globbing only for the above single command, but that is not always easy and requires digging deep into the test suite. Is there a better way?) Ideally, there should be a way to disable globbing in the MinGW startup, but AFAIK this is possible only at compile time, not at run time. Did I miss something? TIA |
From: Earnie <ea...@us...> - 2011-12-26 15:23:10
|
Eli Zaretskii wrote: > The MSYS Bash and the associated MSYS tools work well for configuring > and building MinGW ports (thanks!), but I bumped into an issue when > running the resulting executables from the MSYS Bash. I know that > doing so is asking for trouble, but it is hard to avoid when running > test suites that are part of the packages you just built. > > A case in point is GNU Grep 2.10: running its test suite after > building the MinGW port fails two test (bre and ere) due to a conflict > with globbing command lines between Bash and the grep.exe executable > just built. The problem is that MinGW executables glob the command > line in their startup code, and so commands like this: > > echo '*' | grep '*' > > fail. This fails because grep.exe gets a literal "*" (without > quotes), and globs it in its startup code, which is not what the test > wants. > Google for "CRT_noglob mingw" > Disabling globbing in the MSYS shell completely for the duration of > the test run is not a good idea, because other shell scripts may fail > due to that. > Won't help if you turn off the shell globbing. Windows globs in the startup code of the process. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Eli Z. <el...@gn...> - 2011-12-27 17:31:38
|
> Date: Tue, 27 Dec 2011 07:50:26 -0500 > From: Earnie <ea...@us...> > > >> Google for "CRT_noglob mingw" > > > > Unless I'm missing something, setting CRT_noglob is the compile-time > > way of disabling globbing to which I alluded in my message. If so, > > that's not what I'm looking for, because I _do_ want the MinGW > > compiled grep.exe to glob in its startup code when it is invoked from > > the Windows shell. What I'm looking for is a way to disable globbing > > temporarily at run time, so I could do that for the duration of the > > test suite run, where grep.exe is invoked from the MSYS shell, and the > > latter does the globbing. > > > > I'm not understanding what you're after. If you don't want it to glob > because "that's not what the test wants" then CRT_noglob is how you do > it if you want * to reach main() you must stop the globbing in both bash > and the program start up code. But that is a major inconvenience: I'm building a program to be invoked from the Windows shell, so the built binary must be able to glob its command line in the startup code. It's only during running the test suite that I want the program not to glob, because the MSYS Bash will do it; in routine operation, there's no MSYS Bash anywhere in sight, only cmd.exe. What you suggest is to build the program specially for the test. I hoped that there was some way of disabling globbing dynamically, e.g., by setting some environment variable, without the need to inject special code into the program. > Perhaps you want grep \* instead of grep '*' but I don't think that > is what you're after. "grep \*" fails in the same way as "grep '*'", because Bash removes the quote characters, be it \ or '..', and then Grep sees in its startup code the unquoted * and globs it. |
From: Earnie <ea...@us...> - 2011-12-27 20:17:13
|
Eli Zaretskii wrote: > > "grep \*" fails in the same way as "grep '*'", because Bash removes > the quote characters, be it \ or '..', and then Grep sees in its > startup code the unquoted * and globs it. It is the Windows way. You'll need to code it so that you set "int _CRT_glob = 0"; during the compile of the program for testing. Sorry, no amount of argument will change that fact. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Keith M. <kei...@us...> - 2011-12-28 19:53:35
|
On 27/12/11 17:31, Eli Zaretskii wrote: >> Perhaps you want grep \* instead of grep '*' but I don't think that >> is what you're after. > > "grep \*" fails in the same way as "grep '*'", because Bash removes > the quote characters, be it \ or '..', and then Grep sees in its > startup code the unquoted * and globs it. Probably one of the reasons, (if not the principal one), why Earnie elected to include an MSYS build of grep in the original MSYS suite. MS-Windows globbing, (which is what MinGW uses), doesn't work like POSIX shell globbing:-- 1) As you already realise, you get no help from cmd.exe -- it must be done within each application itself. 2) Only the double quote (") character is explicitly considered to be a quoting character. Single quotes (') are accorded no significance at all, and backslashes are considered to represent escapes only when an odd number of them, in a contiguous run, is immediately followed by a double quote character, (also contiguous with the backslash run). 3) Globbing is NOT inhibited for asterisk (*) or query (?) characters appearing within strings wrapped in double quotes; thus, "*" will be globbed, just as if the quotes were omitted, while \* will be globbed as representing all entities in the root directory of current drive. Only '*' is immune, (and that too will glob, if you happen to have entity names with single quotes as first and last characters -- if indeed that's possible); however, that leaves you with literal '*', (not literal *), which probably isn't what you wanted. So, how do you get a literal asterisk passed to a native application? I guess you'd have to disable Microsoft's globbing algorithm, and provide your own, (or consider the gnulib implementation, which IMO brings too much ancillary baggage with it; however, your opinion may differ, and it may suit your needs). -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2011-12-28 20:58:39
|
> Date: Wed, 28 Dec 2011 15:56:31 +0000 > From: Keith Marshall <kei...@us...> > > On 27/12/11 17:31, Eli Zaretskii wrote: > >> Perhaps you want grep \* instead of grep '*' but I don't think that > >> is what you're after. > > > > "grep \*" fails in the same way as "grep '*'", because Bash removes > > the quote characters, be it \ or '..', and then Grep sees in its > > startup code the unquoted * and globs it. > > Probably one of the reasons, (if not the principal one), why Earnie > elected to include an MSYS build of grep in the original MSYS suite. I know (and I have it installed as part of MSYS). But that's not what my questions were about. I was talking about running the Grep test suite on a MinGW (_not_ MSYS) Grep that was just built, to test the results of the build. That is where the problem happens; there are no problems with running the MSYS Grep from the MSYS Bash. > So, how do you get a literal asterisk passed to a native application? I > guess you'd have to disable Microsoft's globbing algorithm, and provide > your own, (or consider the gnulib implementation, which IMO brings too > much ancillary baggage with it; however, your opinion may differ, and it > may suit your needs). I found that '"*"' does the job, provided that I set noglob in the MSYS Bash. Then Bash removes the '..' single quotes, and the application gets the quoted "*" which is therefore not globbed by the startup code. The problem with this is that you need to identify the test commands which need this kludge and modify only them, which could be tedious, especially if the test commands are themselves generated by a script (e.g., take a look at the Spencer's bre and ere tests in the Grep distro). I thought maybe people more experienced with MSYS will have some tricks up their sleeves to do this in a more elegant way, but I guess what I did was as elegant as it can get. Thanks. |
From: Keith M. <kei...@us...> - 2011-12-30 19:26:54
|
On 28/12/11 20:58, Eli Zaretskii wrote: >>> "grep \*" fails in the same way as "grep '*'", because Bash removes >>> the quote characters, be it \ or '..', and then Grep sees in its >>> startup code the unquoted * and globs it. >> >> Probably one of the reasons, (if not the principal one), why Earnie >> elected to include an MSYS build of grep in the original MSYS suite. > > I know (and I have it installed as part of MSYS). But that's not what > my questions were about. I was talking about running the Grep test > suite on a MinGW (_not_ MSYS) Grep that was just built, to test the > results of the build. Yes, I understood that. It was merely an observation, perhaps of historical interest; there was no implied criticism intended, of your motivation for creating a native w32 build. > That is where the problem happens; Indeed. Reports of quirky behaviour from native builds of grep, sed, etc. are nothing new. > there are no problems with running the MSYS Grep from the MSYS Bash. Nor would we expect them, since both the shell and the application are designed to co-operate, giving a more POSIX like experience. > I found that '"*"' does the job, provided that I set noglob in the > MSYS Bash. Then Bash removes the '..' single quotes, and the > application gets the quoted "*" which is therefore not globbed by the > startup code. Curious. That didn't seem consistent with my own experience, which suggests that quoting the asterisk does NOT prevent globbing by the Microsoft algorithm, so I played with this simple test case: $ cat showargv.c #include <stdio.h> #define WIN32_LEAN_AND_MEAN 1 #include <windows.h> #ifdef __MINGW32_SETARGV int _CRT_glob = __MINGW32_SETARGV; #endif int main( int argc, char **argv) { int i = 0; printf( "command line: <%s>\n", GetCommandLine() ); while( argc-- ) printf( "argv[%d]: %s\n", i++, *argv++ ); return 0; } $ gcc -o showargv.exe showargv.c $ ./showargv '"*"' command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "\"*\""> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: .bash_history argv[2]: .bashrc argv[3]: .hg.cvsps argv[4]: .hgrc argv[5]: .inputrc argv[6]: .lesshst argv[7]: .profile argv[8]: .pwmctrl.pic.swp argv[9]: .viminfo argv[10]: .vimrc Notice how MSYS has passed the quoted asterisk argument as "\"*\"", not as simple "*", and even then it's STILL globbed, expanding to match all the hidden file system entities except . and .. Now, if I switch to cmd.exe: Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Local> cd MSYS\1.0\home\keith C:\Local\MSYS\1.0\home\keith> showargv "*" command line: <showargv "*"> argv[0]: showargv argv[1]: #!.exe argv[2]: .bash_history argv[3]: .bashrc argv[4]: .hg.cvsps ... argv[18]: a.exe ... argv[33]: ebtool-1.0 argv[34]: ebuild ... argv[72]: showargv.c argv[73]: showargv.exe argv[78]: tmp argv[79]: tryme.bat argv[80]: unused.c argv[81]: vimbook-OPL.pdf argv[82]: xx.roff Here we do pass a simple quoted asterisk; notice that it is globbed, just as if it had been unquoted. Also notice that this pattern matches everything, files and directories alike; (it isn't obvious from this listing, but 33, 34, and 78 are directories, while the rest are files). It's hardly surprising that this glob matches all entity names, including those with '.' as initial character, since this naming convention does not have the significance on MS-Windows that POSIX assigns to it; however, it does rather beg the question: why does this form, C:\Local\MSYS\1.0\home\keith> showargv \"*\" command line: <showargv \"*\"> argv[0]: showargv argv[1]: .bash_history argv[2]: .bashrc ... argv[9]: .viminfo argv[10]: .vimrc argv[6]: .lesshst argv[7]: .profile argv[8]: .pwmctrl.pic.swp argv[9]: .viminfo argv[10]: .vimrc which after stripping of quotes, and interpretation of escapes would represent the three character literal "*", as passed in the MSYS case, and not simply the single literal * character, glob to match only the entity names which begin with a . character? Perhaps you could ask Microsoft; there is no rational explanation which I can conceive. Okay. There's nothing in the above to suggest that a quoted * is not globbed; clearly it is. So, why might you be misled into a flawed assumption that it is not? Let's try some of the above again, in a directory with no dotted files; back in MSYS shell: $ mkdir mt $ cd mt $ touch foo bar $ ../showargv '*' command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe *> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: bar argv[2]: foo Not much to surprise us there: unquoted * globs to match the two file names, as we would expect. However: $ ../showargv '"*"' command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "\"*\""> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: "*" in this case argv[1] remains as the literal three characters "*", not because it isn't globbed -- it is -- but because there was nothing for it to match. Also note that it remains as the literal "*"; it does NOT become just the bare * which, if I've understood you correctly, you were expecting. Sorry, but I believe your assumptions are unsafe. Your hack may be good enough, but I don't think it achieves exactly the effect you had hoped it might. If you want 100% POSIX compatible globbing, or even just to have globbing inhibited for quoted arguments, (as it IS in POSIX), then Microsoft's algorithm, as used by MinGW's default application start-up code, will surely disappoint. Finally, BTW, none of the MSYS examples above are affected, in any way, by the state of the shell's noglob setting; that comes into play only when executing commands with UNQUOTED *, such as: $ ../showargv * which, after: $ set -o noglob or, if you prefer: $ set -f behaves just the same as: $ ../showargv "*" or: $ ../showargv '*' or: $ ../showargv \* rather than having the unquoted * globbed by the shell itself. -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2011-12-30 21:05:27
|
> Date: Fri, 30 Dec 2011 13:01:23 +0000 > From: Keith Marshall <kei...@us...> > > $ ./showargv '"*"' > command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "\"*\""> > argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe > argv[1]: .bash_history > argv[2]: .bashrc > argv[3]: .hg.cvsps > argv[4]: .hgrc > argv[5]: .inputrc > argv[6]: .lesshst > argv[7]: .profile > argv[8]: .pwmctrl.pic.swp > argv[9]: .viminfo > argv[10]: .vimrc > > Notice how MSYS has passed the quoted asterisk argument as "\"*\"", > not as simple "*", and even then it's STILL globbed, expanding to match > all the hidden file system entities except . and .. I'm away of the machine where I have MSYS installed, so I cannot test this now; I will do that in a couple of days. But I can test now the example where you invoke the program from cmd.exe: > Now, if I switch to cmd.exe: > > Microsoft Windows [Version 6.0.6002] > Copyright (c) 2006 Microsoft Corporation. All rights reserved. > > C:\Local> cd MSYS\1.0\home\keith > > C:\Local\MSYS\1.0\home\keith> showargv "*" > command line: <showargv "*"> > argv[0]: showargv > argv[1]: #!.exe > argv[2]: .bash_history > argv[3]: .bashrc > argv[4]: .hg.cvsps > ... > argv[18]: a.exe > ... > argv[33]: ebtool-1.0 > argv[34]: ebuild > ... > argv[72]: showargv.c > argv[73]: showargv.exe > argv[78]: tmp > argv[79]: tryme.bat > argv[80]: unused.c > argv[81]: vimbook-OPL.pdf > argv[82]: xx.roff > > Here we do pass a simple quoted asterisk; notice that it is globbed, > just as if it had been unquoted. Also notice that this pattern matches > everything, files and directories alike; (it isn't obvious from this > listing, but 33, 34, and 78 are directories, while the rest are files). I don't know what is happening on your machine, but on mine, I get this: D:\usr\eli\data>..\utils\echocmd "*" `..\utils\echocmd "*"' 0: `..\utils\echocmd' 1: `*' The source (written years ago, btw) is very similar to yours: #include <stdio.h> #include <windows.h> int main (int argc, char *argv[]) { int i = 0; printf ("`%s'\n", GetCommandLine ()); while (argc--) printf ("%d: `%s'\n", i++, *(argv++)); return 0; } The directory where I ran this has 1040 files in it, in case you wonder. If I remove the quotes "..", I indeed get 1040 argv[] elements, as expected. Hmm... Maybe the reason for the difference in behavior is that you are using a later runtime. This discussion: http://connect.microsoft.com/VisualStudio/feedback/details/98756/vs2005-setargv-obj-wildcard-handling-broken indicates that the runtime corresponding to VS2003 did behave as I see on my system, but the runtime corresponding to VS2005 indeed globs even quoted arguments, allegedly to be compatible with the (broken, IMO) handling of quoted arguments by cmd.exe. So can you tell me which version of MS runtime you use to build and run your showargv program? Also, does it help to quote with ^, as in showargv ^* ? If the new setargv is indeed compatible with cmd.exe, it should support the same quoting methods. |
From: Keith M. <kei...@us...> - 2012-01-03 19:34:54
|
On 30/12/11 21:05, Eli Zaretskii wrote: > Hmm... Maybe the reason for the difference in behavior is that you > are using a later runtime. This discussion: > > http://connect.microsoft.com/VisualStudio/feedback/details/98756/vs2005-setargv-obj-wildcard-handling-broken > > indicates that the runtime corresponding to VS2003 did behave as I see > on my system, but the runtime corresponding to VS2005 indeed globs > even quoted arguments, allegedly to be compatible with the (broken, > IMO) handling of quoted arguments by cmd.exe. I did wonder if we might be experiencing behavioural differences between two different MSVCRT.DLL versions. FWIW, I share your opinion that the behaviour I'm seeing is broken, but I'm sure there are many who will say that it's simply different by design. It's precisely this cavalier manner in which Microsoft change an established behaviour of any given product, without regard to backward compatibility, which renders any assumption relating such behaviour as potentially unsafe. > So can you tell me which version of MS runtime you use to build and > run your showargv program? Well, it's built against the libmsvcrt.a IMPORT library from MinGW's mingwrt-3.20-mingw32-dev.tar.gz, but that's mostly irrelevant; the run time behaviour will be dictated by the actual system MSVCRT.DLL which is present; in my case, this is: MSVCRT.DLL version: 7.0.6002.18005 Product version: 6.1.8638.18005 Date modified: 11/04/2009 13:15 > Also, does it help to quote with ^, as in > > showargv ^* With MSYS shell, in my home directory: $ ./showargv '^*' command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe ^*> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: ^* $ ./showargv ^* command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe ^*> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: ^* and after changing to my (effectively) empty directory: $ cd mt $ ../showargv ^* command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe ^*> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: ^* Okay, globbing doesn't produce any expanded result, but I think it was still globbed with no match to the ^* pattern; note that the caret is retained within argv[1]. However, switching to cmd.exe in my MSYS home directory: C:\Local\MSYS\1.0\home\keith> showargv ^* command line: <showargv *> argv[0]: showargv argv[1]: #!.exe argv[2]: .bash_history ... argv[82]: xx.roff Here, the caret appears to have been removed before the application sees the command line, and the remaining bare * is globbed, just as before, so ... > ? If the new setargv is indeed compatible with cmd.exe, it should > support the same quoting methods. ... apparently not. -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2012-01-03 17:43:35
|
> Date: Fri, 30 Dec 2011 13:01:23 +0000 > From: Keith Marshall <kei...@us...> > > $ ../showargv '"*"' > command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "\"*\""> > argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe > argv[1]: "*" > > in this case argv[1] remains as the literal three characters "*", not > because it isn't globbed -- it is -- but because there was nothing for > it to match. Also note that it remains as the literal "*"; it does NOT > become just the bare * which, if I've understood you correctly, you were > expecting. I can confirm that this is what happening. But it was great surprise to me that MSYS does this: > $ ./showargv '"*"' > command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "\"*\""> ^^^^^^^ Why did it put another pair of quotes around the quoted "*"? What I expected was that the shell removes the '..' quotes, and leaves everything else intact, as it does in all other cases: '*' => * 'foo' => foo '"*"' => "\"*\"" ??? This is inconsistent operation, and it all but precludes to pass a quoted wildcard to a MinGW program invoked from the MSYS Bash. That is what defeated my "trick", because I naturally assumed that Bash just removes the outer quotes and that's it. I consider this a bad misfeature of MSYS, at least when it invokes MinGW (not MSYS) programs. Suppose for a moment that I wanted to write my own MinGW command-line globber, by hacking the MinGW's `mainCRTStartup' function to access the Windows command line (with GetCommandLine) and populate argv[] with the globbed arguments. If I did that, I would be unable to provide an unglobbed * to the `main' function, because the additional level of quotes would defeat me! Very bad mojo. |
From: Keith M. <kei...@us...> - 2012-01-04 20:08:15
|
On 03/01/12 17:42, Eli Zaretskii wrote: > I can confirm that this is what happening. But it was great surprise > to me that MSYS does this: > >> $ ./showargv '"*"' >> command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "\"*\""> > ^^^^^^^ > Why did it put another pair of quotes around the quoted "*"? What I > expected was that the shell removes the '..' quotes, and leaves > everything else intact, as it does in all other cases: > > '*' => * > 'foo' => foo > '"*"' => "\"*\"" ??? > > This is inconsistent operation, and it all but precludes to pass a > quoted wildcard to a MinGW program invoked from the MSYS Bash. That > is what defeated my "trick", because I naturally assumed that Bash > just removes the outer quotes and that's it. > > I consider this a bad misfeature of MSYS, at least when it invokes > MinGW (not MSYS) programs. That's your prerogative, but I disagree. The outer quotes would seem to be redundant -- the Microsoft setargv() routine will simply discard them -- but otherwise, MSYS is doing the right thing here. > Suppose for a moment that I wanted to > write my own MinGW command-line globber, by hacking the MinGW's > `mainCRTStartup' function to access the Windows command line (with > GetCommandLine) and populate argv[] with the globbed arguments. If I > did that, ... you would surely disable globbing within setargv(), (by setting _CRT_glob = 0, as an initialised global variable), so you would be able to pass an unglobbed *; however, you would still be faced by the issue of identifying where the MSYS shell has removed quoting, where cmd.exe would not have done, (i.e., how do you identify where YOUR globbing function should treat the * as quoted?). The real issue isn't the globbing, as such, but rather the incompatible handling of quote reduction between cmd.exe and MSYS shell. > I would be unable to provide an unglobbed * to the `main' > function, because the additional level of quotes would defeat me! In this particular (special) situation, yes, you have an extremely difficult problem; this is always going to arise, where you have two incompatible mechanisms competing to deliver the same effect; (here, the normal quote reduction performed by the MSYS shell, competing with setargv()'s performance of the same function, in order to compensate for cmd.exe not doing it). In the command: ./setargv '"*"' you express an intent to pass the literal three character string "*" as argv[1]. The MSYS shell itself will remove the outer layer of single quotes, and, armed with the knowledge that setargv() will swallow the next level, defeating your apparent intent, it takes the only possible action available, to protect them -- it escapes them. If you don't believe that this is the correct thing to do, then try compiling and running this variant of showargv.c on any *nix host: $ uname -a Linux ... 2.6.35-28-generic #50-Ubuntu SMP ... i686 GNU/Linux $ cat showargv.c #include <stdio.h> #ifdef _WIN32 # define WIN32_LEAN_AND_MEAN 1 # include <windows.h> # ifdef __MINGW32_SETARGV int _CRT_glob = __MINGW32_SETARGV; # endif # define PRINT_W32_COMMAND_LINE \ printf( "command line: <%s>\n", GetCommandLine() ); #else # define PRINT_W32_COMMAND_LINE #endif int main( int argc, char **argv) { int i = 0; PRINT_W32_COMMAND_LINE while( argc-- ) printf( "argv[%d]: %s\n", i++, *argv++ ); return 0; } $ gcc -o showargv showargv.c $ ./showargv '"*"' argv[0]: ./showargv argv[1]: "*" and, as it SHOULD also be on windows, but for setargv()'s degenerate globbing of quoted *, which needs _CRT_glob = 0 to correct: $ ./showargv "*" argv[0]: ./showargv argv[1]: * > Very bad mojo. On the contrary, MSYS is doing the best it can to ensure that, for the same command line, the argument vector seen by the application is the same as it would be, for the equivalent application running on *nix. It is unfortunate that this (otherwise correct) behaviour interferes with your kludge to work around an (IOO broken) effect of Microsoft's setargv() implementation. FWIW, I was not involved in the development of this aspect of MSYS, but I did write the quotearg.c implementation used by groff, where I [*] used identically the same quoting mechanism, (independently developed), to ensure that white space and embedded quotation would pass through setargv() unscathed, when passed via the argument vector in a spawnvp() call; (I also wrapped each entire argument, when modified, and sometimes perhaps redundantly, within an outer level of quoting, just as MSYS does, because in my implementation that also served as an indicator of where I later needed to clean up the heap memory pool). [*] If you inspect that groff code, you may observe that it has been attributed to Jeff Conrad and myself. Jeff and I did, indeed, bounce our ideas around between us, with some additional minor contributions from Werner Lemberg, but it was I who wrote the final implementation. -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2012-01-04 21:46:07
|
> Date: Wed, 04 Jan 2012 20:06:37 +0000 > From: Keith Marshall <kei...@us...> > > > '*' => * > > 'foo' => foo > > '"*"' => "\"*\"" ??? > > > > This is inconsistent operation, and it all but precludes to pass a > > quoted wildcard to a MinGW program invoked from the MSYS Bash. That > > is what defeated my "trick", because I naturally assumed that Bash > > just removes the outer quotes and that's it. > > > > I consider this a bad misfeature of MSYS, at least when it invokes > > MinGW (not MSYS) programs. > > That's your prerogative, but I disagree. The outer quotes would seem to > be redundant -- the Microsoft setargv() routine will simply discard them > -- but otherwise, MSYS is doing the right thing here. The outer quotes _are_ the problem: they prevent setargv from doing what is expected here -- produce a single * in argv[1]. > > Suppose for a moment that I wanted to > > write my own MinGW command-line globber, by hacking the MinGW's > > `mainCRTStartup' function to access the Windows command line (with > > GetCommandLine) and populate argv[] with the globbed arguments. If I > > did that, > > ... you would surely disable globbing within setargv(), (by setting > _CRT_glob = 0, as an initialised global variable), so you would be able > to pass an unglobbed * You are missing the point. I want a globber that will glob unquoted *, but not a quoted one. That is currently impossible when invoking MinGW programs from the MSYS shell, due to the extra quotes. > however, you would still be faced by the issue of identifying where > the MSYS shell has removed quoting, where cmd.exe would not have > done There's no need, each shell should issue a different command line: "*" with cmd.exe, '"*"' with Bash. We cannot expect the same command line to do the same in both shells, since they are so different. > In this particular (special) situation, yes, you have an extremely > difficult problem I don't see any difficulties. Someone must have written code to specifically add an extra pair of quotes to such arguments; that code should be disabled in case of a MinGW program (as opposed to an MSYS program). > In the command: > > ./setargv '"*"' > > you express an intent to pass the literal three character string "*" as > argv[1]. No, I did not. I expressed the intent that the shell removes the outer quotes and leaves the rest to the program it invokes. It shouldn't second-guess what the program will or won't do with the result. > The MSYS shell itself will remove the outer layer of single > quotes, and, armed with the knowledge that setargv() will swallow the > next level, defeating your apparent intent, it takes the only possible > action available, to protect them -- it escapes them. The MSYS shell should not second-guess me. It should do what it's told, and do it consistently. If I want an extra pair of quotes, I will add them myself. > $ gcc -o showargv showargv.c > > $ ./showargv '"*"' > argv[0]: ./showargv > argv[1]: "*" > > and, as it SHOULD also be on windows, but for setargv()'s degenerate > globbing of quoted *, which needs _CRT_glob = 0 to correct: > > $ ./showargv "*" > argv[0]: ./showargv > argv[1]: * Irrelevant: Windows is not Unix, and cmd is not a Posix shell. We _do_ need tricks and kludges to get our job done on Windows. By adding an extra pair of quotes, MSYS robs me of the only fire escape I have to prevent globbing and still get * to the program's main function. > > Very bad mojo. > > On the contrary, MSYS is doing the best it can to ensure that, for the > same command line, the argument vector seen by the application is the > same as it would be, for the equivalent application running on *nix. When I need Unix-like operation, I invoke an MSYS program. When I invoke a MinGW program, I don't _expect_ 100% Unix compatibility. |
From: Keith M. <kei...@us...> - 2012-01-05 20:23:24
|
On 04/01/12 21:44, Eli Zaretskii wrote: > The outer quotes _are_ the problem: No, they are not... > they prevent setargv from doing > what is expected here -- produce a single * in argv[1]. ...it is the ESCAPED quotes which do that. The outer quotes are redundant, and are simply discarded by setargv(); they have no effect on the interpretation of the argument whatsoever. > You are missing the point. On the contrary, I understood your point perfectly; it is you who are missing the point. >> In the command: >> >> ./setargv '"*"' >> >> you express an intent to pass the literal three character string "*" as >> argv[1]. > > No, I did not. Really? Whether it was your intent, or not, that IS the intent expressed by that command, (in terms of Bourne shell grammar). >> ... examples of the same command, run on GNU/Linux, snipped ... > > Irrelevant: Windows is not Unix, and cmd is not a Posix shell. Once again on the contrary, it is completely relevant. The comparison was not between cmd.exe and GNU/Linux bash, but rather, it was between MSYS bash, (a rudimentary POSIX emulating environment), and another POSIX environment, when running a specific command compiled from the same source in each case; the behaviour should be the same for both. The design intent of MSYS is to provide a platform emulating POSIX to a sufficient extent to run Bourne shell scripts on windows; any program which may be run from any such script MUST exhibit identically the same behaviour as it would exhibit on a real POSIX platform. > When I need Unix-like operation, I invoke an MSYS program. When I > invoke a MinGW program, I don't _expect_ 100% Unix compatibility. Then your expectations are flawed. To be sure, I don't expect 100% unix compatibility either, but if I write a shell script such as: #! /bin/sh gcc -o showargv showargv.c ./showargv '"*"' then I do expect to see identical interpretation of argv[1] whether I run it on GNU/Linux, or on windows under MSYS (where it runs MinGW-GCC as the compiler). With the present implementation, that's exactly what I do see; you would have me break that. MSYS is doing the right thing here. Until you accept that fundamental reality, further discussion seems pointless. Unless you wish to offer proactive suggestions, which do not entail breaking existing correct functionality, I have no more to say on the matter. -- Regards, Keith. |
From: Eli Z. <el...@gn...> - 2012-01-05 20:56:23
|
> Date: Thu, 05 Jan 2012 15:06:22 +0000 > From: Keith Marshall <kei...@us...> > > #! /bin/sh > gcc -o showargv showargv.c > ./showargv '"*"' > > then I do expect to see identical interpretation of argv[1] whether I > run it on GNU/Linux, or on windows under MSYS (where it runs MinGW-GCC > as the compiler). With the present implementation, that's exactly what > I do see; you would have me break that. > > MSYS is doing the right thing here. A "feature" that leaves the users without a fire escape can never be "right". The upshot of all this "right thing" is that there's no way to pass an unquoted * to MinGW programs, be it GCC or something else. It is unfortunate that you don't see how this is bad. "Breaking" it would mean that there would be _some_ way of getting a * into a program, albeit a way that requires slightly different commands in each case. That is a lesser evil than not having a way at all. |
From: Earnie B. <ea...@us...> - 2012-01-06 13:48:19
|
On Thu, Jan 5, 2012 at 3:54 PM, Eli Zaretskii <el...@gn...> wrote: > > Date: Thu, 05 Jan 2012 15:06:22 +0000 > > From: Keith Marshall <kei...@us...> > > > > #! /bin/sh > > gcc -o showargv showargv.c > > ./showargv '"*"' > > > > then I do expect to see identical interpretation of argv[1] whether I > > run it on GNU/Linux, or on windows under MSYS (where it runs MinGW-GCC > > as the compiler). With the present implementation, that's exactly what > > I do see; you would have me break that. > > > > MSYS is doing the right thing here. > > A "feature" that leaves the users without a fire escape can never be > "right". The upshot of all this "right thing" is that there's no way > to pass an unquoted * to MinGW programs, be it GCC or something else. > It is unfortunate that you don't see how this is bad. > While I agree with this statement I don't agree that MSYS is broken, see below. > > "Breaking" it would mean that there would be _some_ way of getting a * > into a program, albeit a way that requires slightly different commands > in each case. That is a lesser evil than not having a way at all. > > Adding /mingw/lib/CRT_noglob.o to the build of showargv you will see: $ showargv '*' command line: <"c:\mnt\home\Earnie Boyd\spud\showargv.exe" *> argv[0]: c:\mnt\home\Earnie Boyd\spud\showargv.exe argv[1]: * So you have a way to get a * into the Windows program as long as you follow the Windows rules. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-01-06 21:35:00
|
On 05/01/12 20:54, Eli Zaretskii wrote: >> Date: Thu, 05 Jan 2012 15:06:22 +0000 >> From: Keith Marshall >> >> #! /bin/sh >> gcc -o showargv showargv.c >> ./showargv '"*"' >> >> then I do expect to see identical interpretation of argv[1] whether I >> run it on GNU/Linux, or on windows under MSYS (where it runs MinGW-GCC >> as the compiler). With the present implementation, that's exactly what >> I do see; you would have me break that. >> >> MSYS is doing the right thing here. > > A "feature" that leaves the users without a fire escape can never be > "right". The upshot of all this "right thing" is that there's no way > to pass an unquoted * to MinGW programs, be it GCC or something else. > It is unfortunate that you don't see how this is bad. What is unfortunate is the arrogant manner in which you assume that anyone who dares to disagree with your evaluation of a problem must be wrong; I know that you aren't stupid, so why must you portray yourself as such a pompous ass? > "Breaking" it would mean that there would be _some_ way of getting a * > into a program, No, sorry, but you are losing sight of the real problem here. In fact, just getting a * into the program is as easy as: $ ./showargv '*' command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe *> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: * Of course, this just puts us back at square one; unless we've built showargv.exe with globbing disabled, (and I agree with you here; this is not the solution we want to adopt), Microsoft's setargv() is going to glob the bare * so passed; (indeed, even if it could be passed as "*" in the command line, such that setargv() would strip away the enclosing quotes, some versions of setargv() may STILL glob it). > albeit a way that requires slightly different commands in each case. > That is a lesser evil than not having a way at all. It should not be necessary to have different commands for each case. You have suggested: $ ./showargv '"*"' This DEFINITELY is NOT an appropriate solution. I've already stated that MSYS does exactly the right thing in this case, and I resolutely remain of that opinion. However, this in no way implies that I think MSYS is doing everything right; it obviously isn't. I invited you to offer proactive suggestions. You have apparently declined, so let me offer one: to achieve an appropriate solution to this problem, two things need to happen:-- 1) An alternative implementation of setargv() must be provided, to avoid globbing of wild card characters where these have been flagged, e.g. by quoting, to exempt them from globbing; this will be required to replace the system provided implementation, for recent windows versions which exhibit Microsoft's current (arguably broken) behaviour. 2) The code within MSYS bash which prepares the command line for the spawned windows command must be augmented, such that it satisfies the requirement to appropriately flag any wild card characters which are to be exempt from globbing. Thus, in addition to the already correct handling of: $ ./showargv "foo bar" command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "foo bar"> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: foo bar where quoting is reinstated in the passed command line, to demarcate the single argument containing embedded white space, and: $ ./showargv '"*"' command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "\"*\""> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: "*" where escapes are added, to flag the literal (i.e. non-reducible) quotes -- it could be argued that the outer reducible quotes are unnecessary here, but the presence of the globbing character would actually negate that argument -- it needs to be augmented to correct these two cases: $ ./showargv "foo*bar" command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe foo*bar> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: foobar argv[2]: foo.bar ... $ ./showargv "foo?bar" command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe foo?bar> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: foo.bar ... Notice that in both these cases, due to quoting on the shell command line, the globbing characters are exempt from globbing; the shell MUST have identified this, and so these arguments could have been passed on to the spawned command thus, (with reducible quotes inserted): $ ./showargv "foo?bar" command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "foo*bar"> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: foo*bar $ ./showargv "foo?bar" command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "foo?bar"> argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe argv[1]: foo?bar With this adjustment, coupled with an appropriate implementation of setargv(), (which doesn't glob arguments where wild cards appear in a quoted context), the problem you've reported should no longer arise. I think this represents an accurate analysis of the problem, together with a reasoned proactive proposal for how it might be resolved; it is certainly more likely to receive favourable consideration by the MSYS maintainers than your unreasoned and, in the final analysis, seemingly inaccurately founded rant. -- Regards, Keith. |
From: Edward D. <eld...@tr...> - 2012-01-10 19:24:25
|
On 1/6/2012 4:34 PM, Keith Marshall wrote: > On 05/01/12 20:54, Eli Zaretskii wrote: >>> Date: Thu, 05 Jan 2012 15:06:22 +0000 >>> From: Keith Marshall >>> >>> #! /bin/sh >>> gcc -o showargv showargv.c >>> ./showargv '"*"' >>> >>> then I do expect to see identical interpretation of argv[1] whether I >>> run it on GNU/Linux, or on windows under MSYS (where it runs MinGW-GCC >>> as the compiler). With the present implementation, that's exactly what >>> I do see; you would have me break that. >>> >>> MSYS is doing the right thing here. >> >> A "feature" that leaves the users without a fire escape can never be >> "right". The upshot of all this "right thing" is that there's no way >> to pass an unquoted * to MinGW programs, be it GCC or something else. >> It is unfortunate that you don't see how this is bad. > > What is unfortunate is the arrogant manner in which you assume that > anyone who dares to disagree with your evaluation of a problem must be > wrong; I know that you aren't stupid, so why must you portray yourself > as such a pompous ass? I think you are being extremely unfair to the responder. He is just arguing his case, very reasonably I might add, and you disagree with it as he disagrees with you. There is no point of accusing him of being "a pompous ass". |
From: Eli Z. <el...@gn...> - 2011-12-26 17:03:21
|
> Date: Mon, 26 Dec 2011 10:22:58 -0500 > From: Earnie <ea...@us...> > > > echo '*' | grep '*' > > > > fail. This fails because grep.exe gets a literal "*" (without > > quotes), and globs it in its startup code, which is not what the test > > wants. > > > > Google for "CRT_noglob mingw" Unless I'm missing something, setting CRT_noglob is the compile-time way of disabling globbing to which I alluded in my message. If so, that's not what I'm looking for, because I _do_ want the MinGW compiled grep.exe to glob in its startup code when it is invoked from the Windows shell. What I'm looking for is a way to disable globbing temporarily at run time, so I could do that for the duration of the test suite run, where grep.exe is invoked from the MSYS shell, and the latter does the globbing. > > Disabling globbing in the MSYS shell completely for the duration of > > the test run is not a good idea, because other shell scripts may fail > > due to that. > > > > Won't help if you turn off the shell globbing. Windows globs in the > startup code of the process. But if the MSYS shell does not glob, then the quotes that protect the widlcard will wind up verbatim in the startup code, and disable globbing. Anyway, as I said, this is not a good idea for other reasons. Thanks. |
From: Earnie <ea...@us...> - 2011-12-27 12:50:37
|
Eli Zaretskii wrote: >> Date: Mon, 26 Dec 2011 10:22:58 -0500 >> From: Earnie <ea...@us...> >> >>> echo '*' | grep '*' >>> >>> fail. This fails because grep.exe gets a literal "*" (without >>> quotes), and globs it in its startup code, which is not what the test >>> wants. >>> >> >> Google for "CRT_noglob mingw" > > Unless I'm missing something, setting CRT_noglob is the compile-time > way of disabling globbing to which I alluded in my message. If so, > that's not what I'm looking for, because I _do_ want the MinGW > compiled grep.exe to glob in its startup code when it is invoked from > the Windows shell. What I'm looking for is a way to disable globbing > temporarily at run time, so I could do that for the duration of the > test suite run, where grep.exe is invoked from the MSYS shell, and the > latter does the globbing. > I'm not understanding what you're after. If you don't want it to glob because "that's not what the test wants" then CRT_noglob is how you do it if you want * to reach main() you must stop the globbing in both bash and the program start up code. >>> Disabling globbing in the MSYS shell completely for the duration of >>> the test run is not a good idea, because other shell scripts may fail >>> due to that. >>> >> >> Won't help if you turn off the shell globbing. Windows globs in the >> startup code of the process. > > But if the MSYS shell does not glob, then the quotes that protect the > widlcard will wind up verbatim in the startup code, and disable > globbing. > > Anyway, as I said, this is not a good idea for other reasons. > Still not understanding you. Perhaps you want grep \* instead of grep '*' but I don't think that is what you're after. -- Earnie -- https://sites.google.com/site/earnieboyd/ |
From: Eli Z. <el...@gn...> - 2011-12-27 21:55:59
|
> Date: Tue, 27 Dec 2011 15:17:00 -0500 > From: Earnie <ea...@us...> > > Eli Zaretskii wrote: > > > > "grep \*" fails in the same way as "grep '*'", because Bash removes > > the quote characters, be it \ or '..', and then Grep sees in its > > startup code the unquoted * and globs it. > > It is the Windows way. You'll need to code it so that you set "int > _CRT_glob = 0"; during the compile of the program for testing. Sorry, > no amount of argument will change that fact. I wasn't looking for an argument. I asked whether there was a better way than what I did (hack the test scripts). I guess it's a "no"; thanks. |
From: Eli Z. <el...@gn...> - 2012-01-03 20:11:46
|
> Date: Tue, 03 Jan 2012 13:19:39 +0000 > From: Keith Marshall <kei...@us...> > > > So can you tell me which version of MS runtime you use to build and > > run your showargv program? > > Well, it's built against the libmsvcrt.a IMPORT library from MinGW's > mingwrt-3.20-mingw32-dev.tar.gz, but that's mostly irrelevant; the run > time behaviour will be dictated by the actual system MSVCRT.DLL which is > present; in my case, this is: > > MSVCRT.DLL version: 7.0.6002.18005 > Product version: 6.1.8638.18005 > Date modified: 11/04/2009 13:15 It's 7.0.2600.3085 here, dated 8/4/2004. |
From: Eli Z. <el...@gn...> - 2012-01-06 15:06:47
|
> Date: Fri, 6 Jan 2012 08:48:12 -0500 > From: Earnie Boyd <ea...@us...> > > > "Breaking" it would mean that there would be _some_ way of getting a * > > into a program, albeit a way that requires slightly different commands > > in each case. That is a lesser evil than not having a way at all. > > > > > Adding /mingw/lib/CRT_noglob.o to the build of showargv you will see: > > $ showargv '*' > command line: <"c:\mnt\home\Earnie Boyd\spud\showargv.exe" *> > argv[0]: c:\mnt\home\Earnie Boyd\spud\showargv.exe > argv[1]: * > > So you have a way to get a * into the Windows program as long as you follow > the Windows rules. While this is true, such a showargv would not be a useful program when invoked from the Windows shell. To recap, all this came out of a discussion of how to run a MinGW build of Grep through its test suite using the MSYS shell. Surely, you do not seriously suggest to build a MinGW Grep with globbing disabled. And Grep is just an example here; any package that has a reasonably complex test suite will need the MSYS shell to run it, after building with MinGW. |
From: Earnie B. <ea...@us...> - 2012-01-06 16:29:23
|
On Fri, Jan 6, 2012 at 10:04 AM, Eli Zaretskii <el...@gn...> wrote: > > Date: Fri, 6 Jan 2012 08:48:12 -0500 > > From: Earnie Boyd <ea...@us...> > > > > > "Breaking" it would mean that there would be _some_ way of getting a * > > > into a program, albeit a way that requires slightly different commands > > > in each case. That is a lesser evil than not having a way at all. > > > > > > > > Adding /mingw/lib/CRT_noglob.o to the build of showargv you will see: > > > > $ showargv '*' > > command line: <"c:\mnt\home\Earnie Boyd\spud\showargv.exe" *> > > argv[0]: c:\mnt\home\Earnie Boyd\spud\showargv.exe > > argv[1]: * > > > > So you have a way to get a * into the Windows program as long as you > follow > > the Windows rules. > > While this is true, such a showargv would not be a useful program when > invoked from the Windows shell. > > Why not? c:\mnt\home\Earnie Boyd\spud>showargv "*" command line: <showargv "*"> argv[0]: showargv argv[1]: * > To recap, all this came out of a discussion of how to run a MinGW > build of Grep through its test suite using the MSYS shell. Surely, > you do not seriously suggest to build a MinGW Grep with globbing > disabled. And Grep is just an example here; any package that has a > reasonably complex test suite will need the MSYS shell to run it, > after building with MinGW. > > Oh, now you're talking yourself into silly circles. *You* made an argument that MSYS couldn't pass an * into the program. I showed that MSYS can in fact do just that. *You* made an argument that you might want to parse the * yourself but you were not seeing a way to have MSYS send it just a * when in fact MSYS can. As for the Grep test suite, unless you disable the globbing in the program with _CRT_glob = 0 then you cannot do what you want to do. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2012-01-06 16:57:43
|
> Date: Fri, 6 Jan 2012 11:29:16 -0500 > From: Earnie Boyd <ea...@us...> > > > While this is true, such a showargv would not be a useful program when > > invoked from the Windows shell. > > > > > Why not? > > c:\mnt\home\Earnie Boyd\spud>showargv "*" > command line: <showargv "*"> > argv[0]: showargv > argv[1]: * Because of the "showargv *" use case. > As for the Grep test suite, unless you disable the > globbing in the program with _CRT_glob = 0 then you cannot do what you want > to do. Which is unfortunate. |
From: Eli Z. <el...@gn...> - 2012-01-07 09:23:11
|
> Date: Fri, 06 Jan 2012 21:34:25 +0000 > From: Keith Marshall <kei...@us...> > > > A "feature" that leaves the users without a fire escape can never be > > "right". The upshot of all this "right thing" is that there's no way > > to pass an unquoted * to MinGW programs, be it GCC or something else. > > It is unfortunate that you don't see how this is bad. > > What is unfortunate is the arrogant manner in which you assume that > anyone who dares to disagree with your evaluation of a problem must be > wrong; I know that you aren't stupid, so why must you portray yourself > as such a pompous ass? That's hardly an efficient way of convincing me. Actually, what I wrote is in no way arrogant. Opinionated, maybe, but those opinions _are_ based on my share of fighting for quite a few years the uphill battle with MS idiosyncrasies. What I wrote was an expression of a frustration of a user who is faced with software that blocks every possible way around a problem short of compiling all kinds of unclean tricks into the application, just to be able to run a test suite. Treating this as "arrogance" is bewildering at best. Also note that Earnie did agree with the principle that there should be a fire escape. > You have suggested: > > $ ./showargv '"*"' > > This DEFINITELY is NOT an appropriate solution. It was supposed to be a work-around, a kludge, nothing more. > I invited you to offer proactive suggestions. You have apparently > declined I don't know enough about MSYS to suggest how to change it. Useful change suggestions must be based on good understanding of the current operation, which I don't have. I did suggest a solution, albeit implicitly. In the beginning of this thread, I asked whether there was some way of telling the MinGW startup to refrain from globbing, by some external means, such as an environment variable. A program that is run by a Posix shell should not glob at all, as the shell does it for it. Therefore, if there were a way to turn off the "internal" globbing, the MSYS shell should have done that always, and that would be a good solution, an alternative to what you suggest below. > 1) An alternative implementation of setargv() must be provided, to avoid > globbing of wild card characters where these have been flagged, e.g. by > quoting, to exempt them from globbing; this will be required to replace > the system provided implementation, for recent windows versions which > exhibit Microsoft's current (arguably broken) behaviour. > > 2) The code within MSYS bash which prepares the command line for the > spawned windows command must be augmented, such that it satisfies the > requirement to appropriately flag any wild card characters which are to > be exempt from globbing. That would be fine as well. My point was that without some changes on the MSYS side, part (2) above, the first part alone is not enough to solve this issue for MinGW programs, even if a replacement setargv is written. > Notice that in both these cases, due to quoting on the shell command > line, the globbing characters are exempt from globbing; the shell MUST > have identified this, and so these arguments could have been passed on > to the spawned command thus, (with reducible quotes inserted): > > $ ./showargv "foo?bar" > command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "foo*bar"> > argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe > argv[1]: foo*bar > > $ ./showargv "foo?bar" > command line: <C:\Local\MSYS\1.0\home\keith\showargv.exe "foo?bar"> > argv[0]: C:\Local\MSYS\1.0\home\keith\showargv.exe > argv[1]: foo?bar > > With this adjustment, coupled with an appropriate implementation of > setargv(), (which doesn't glob arguments where wild cards appear in a > quoted context), the problem you've reported should no longer arise. Since the setargv implementation I'm dealing with already doesn't glob quoted wildcard characters, the only part that I was missing is the change in MSYS as you described above. That is, when spawning a MinGW program, pass "SOMETHING" intact to the program, and let its internal globbing do its usual thing. Note that this "leave-quotes-alone" issue is complicated by what can be inside the quotes. E.g., if could be "`some-command ?`", in which case the back-ticks should be expanded before passing the quoted argument to MinGW. I'm sure you are ware of that. > I think this represents an accurate analysis of the problem, together > with a reasoned proactive proposal for how it might be resolved; it is > certainly more likely to receive favourable consideration by the MSYS > maintainers than your unreasoned and, in the final analysis, seemingly > inaccurately founded rant. Looking forward to seeing this enhancement in one of the future MSYS releases. TIA |