Windows: ZeroBrane built-in lua interpreters perform unavoidable command line file globbing

[tmcdaniel-aspyr]

On Windows, the lua interpreters built into ZeroBrane perform command line file globbing. At least they do within the IDE debugger, setting the command line parameters through Project > Command Line Parameters. I haven't tried them outside the IDE. This is rather unusual behavior for a Windows executable. Further, I can't find a way to avoid the globbing. The typical method of quoting a command line arg doesn't work, the globbing still occurs. e.g. D:\some\path\* "D:\some\path\*" ""D:\some\path\*"" """D:\some\path\*""" The first 3 perform globbing, the 4th passes "D:\some\path\*" (with the quotes) into the script. There's no way to pass D:\some\path\* through to the script.

[pkulchenko]

@tmcdaniel-aspyr, thank you for the interesting report. You sent me on a wild goose chase to find what's happening here. I can confirm that this is definitely happening, but I can't figure out which of the components is responsible for it. First of all, I thought it was something that wxwidgets does, but this doesn't seem to be the case, as I can't find any relevant code in wxExecute that would do this. Then I found some old discussions about mingw being responsible, and indeed there is a long comment in _mingw.h describing the globbing logic:

/* _dowildcard is an int that controls the globbing of the command line.
 * The MinGW32 (mingw.org) runtime calls it _CRT_glob, so we are adding
 * a compatibility definition here:  you can use either of _CRT_glob or
 * _dowildcard .
 * If _dowildcard is non-zero, the command line will be globbed:  *.*
 * will be expanded to be all files in the startup directory.
 * In the mingw-w64 library a _dowildcard variable is defined as being
 * 0, therefore command line globbing is DISABLED by default. To turn it
 * on and to leave wildcard command line processing MS's globbing code,
 * include a line in one of your source modules defining _dowildcard and
 * setting it to -1, like so:
 * int _dowildcard = -1;
 */
#undef  _CRT_glob
#define _CRT_glob _dowildcard

Even with this description I don't see _dowildcard being set anywhere. I also checked a plain Lua interpreter and it does show the same behavior (outside of the IDE), so it doesn't seem to be IDE related. The IDE itself does not expand wildcards, but it does its own command line processing (build/win32_starter.c), so I still suspect it may be something to do with mingw processing, but can't find where.

The only workaround I found so far is to do what you did: wrap your argument into single quotes and then remove the quotes before processing those parameters; you can probably apply it at the top of your script to all arg values to make the logic simpler.

[pkulchenko]

I think it's mingw; I found this in the source of libcrt:

 * This file is implicitly linked into any executable using libmingwex.a; it
 * defines the global variable, _CRT_glob, with a default value which enables
 * globbing of command line arguments, using mingw32's basic implementation
 * of the POSIX globbing algorithm.  To override this default behaviour:
 *
 * - Explicitly include the object module CRTnoglob.o in your link command;
 *   this defines _CRT_glob = 0, so disabling command line globbing.
 *
 * - Alternatively, explicitly define _CRT_glob as a global variable in one
 *   of your own source modules, assigning any of the related values defined
 *   in _mingw.h, to enable alternative globbing algorithms and/or features,
 *   or zero to disable globbing.

If this works, it will require re-compilation of lua executables for all supported versions. I'll give it a try in a bit.

[tmcdaniel-aspyr]

@pkulchenko Thanks for investigating! One extra data point: We build luajit for Win x64 using llvm-mingw, using all default settings, and it does not exhibit this globbing behavior.

[pkulchenko]

@tmcdaniel-aspyr, thank you for the update; it definitely looks to be toolkit/configuration specific.

BTW, you can replace the version that ships with the IDE and use your own (if you can compile it for x86 instead of x64).

Or you can configure it to run as an external interpreter; see https://studio.zerobrane.com/doc-general-preferences#interpreter-path