lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Sorry for the late reply.

On 08/12/2011 15.36, Jerome Vuarand wrote:
2011/12/8 Lorenzo Donati<>:
Running the test suite with:

..\src\lua -e"_U=true" all.lua

was ok, but note that I had to change single quotes into double quotes.
When using (as suggested in

..\src\lua -e'_U=true' all.lua

with XP command prompt I got the error:

..\src\lua: (command line):1: unexpected symbol near ''_U=true''

That's because of the way the C runtime library splits command line
and handles quoting. Contrary to Unix, the Windows command lines are
passed as a single string to the called process, and the C runtime
library is splitting it into argc and argv. The C runtime library
you're using seems not to handle single quotes like you expect. If
it's anything like CommandLineToArgcW function [1] (which I believe
the MSVC libc is calling), it only treats double quotes specially and
pass single quotes unchanged (and the string [[ '_U=true' ]] is not
valid Lua code).

Well, I don't think it's an issue with a faulty/weird C runtime. I don't know why the single quotes are there in the original command line (I suppose they are needed on *NIX systems - I don't know very much bash shell quoting rules).

If, as it appears, the purpose is to set the global _U, on windows should be sufficient to write -e_U=true. In fact if on the command line I write:

lua52 -E -e_U=true;print(_U)

It prints "true" (with no quotes).

Those double quotes I put are interpreted (and stripped) by the windows shell (IIRC), not the C runtime. AFAIK single quotes are ordinary characters for the Windows shell, so writing -e'_U=true' will try to make the interpreter execute a string, not a statement (as you point out).

Maybe on there should be a mention that on windows systems that invocation won't work and that single quotes must be left out.


-- Lorenzo