Archive: changed command line behaviour for makensisw in v.2.25?
changed command line behaviour for makensisw in v.2.25?
Hi,
i compile my scripts by batch file. I use the following code:
start ..\..\NSISCompiler\makensisw.exe /DSOME_DEFINE scriptfile.nsi
Unfortunately the doesn't work anymore in 2.25. It seems to me that makensisw treats every parameter as a filename as therefor fails to open /DSOME_DEFINE.
Can anyone confirm?
Regards
Flizebogen
Try:
start "..\..\NSISCompiler\makensisw.exe" "/DSOME_DEFINE scriptfile.nsi"
Stu
No that gives only a different error message. This time provided by makensis and not the wrapper
cmdline behaviour hasnt changed, just tested, works fine for me.
problem on first post:
the /D switch is interpreted by the "start" command itself, so it won't work. type "start /?" in your cmdline and read :)
problem on the second post:
afrows solution is right, but you should not call "makensisw.exe" but "makensis.exe"
makensisw is just a GUI wrapper for the makensis cmdline compiler.
when using start and quoted paths on NT, you need to provide a title aswell (very stupid move by MS)
try: start "" "..\..\NSISCompiler\makensis.exe" /DSOME_DEFINE scriptfile.nsi
I tested it on a second XP machine and the problem is there too.
There are various reasons for using makensisw instead of the compiler itself.
- Log of compilation is cut off in ms-dos box
- possibility to recompile
I used the start command to immediate close the dos box.
@anders
Yes the online help for start says the first parameter should be the title but the command is also executed if the title is missing.
@ Afrow UK
If i quote everything than i'm forced to add a title for the "start" command. But this still doesn't work. The error message i get is:
Command line defined: "SOMEDEFINE scriptname.nsi"
If i drop the "start" command and call makensisw directly without quoting i get the following message:
MakeNSIS v2.25- Copyright 1995-2007 Contributors
See the file COPYINGfor license details.
>Credits can be found in the Users Manual.
>Cant open script "/DSOMEDEFINE"
If i change the call to makensis.exe then it compiles fine regardless of the not set Title for the "start" command. It also compiles fine if i use the makensisw.exe (v.2.2) from nsis 2.24.Command line handling has changed for MakeNSISw v2.3. It passes `--` to escape the script name now that makensis supports both dash and slash as the switch escape code. Please open a bug report for it.
"v2.3" ? possibly since v2.23?
No
Makensisw.exe v.2.3 is shipped with nsis 2.25
Makensisw.exe v.2.2 is shipped with nsis 2.24
Ah, sorry plus the "w", I never see and use, I need to put of my :cool:
strange, I have a similar problem with MakeNSISw (Release 2.30)
This doesn't work
start "" "%NSISDIR%\makensisw.exe" /DABCDEFGHIJKLMNOPQ=1 /DABCDEFGHI=2 Update.nsi
MakeNSIS v2.30 - Copyright 1995-2007 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.
Processing config:
Processing plugin dlls: "C:\Program Files\NSIS\Plugins\*.dll"
...
start "" "%NSISDIR%\makensisw.exe" /DABCDEFGHIJKLMNOPQ=1 /DABCDEFGH=2 Update.nsi
MakeNSIS v2.30 - Copyright 1995-2007 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.
Command line defined: "ABCDEFGHIJKLMNOPQ=1"
Command line defined: "ABCDEFGH=2"
Processing config:
Processing plugin dlls: "C:\Program Files\NSIS\Plugins\*.dll"
...
This does not happen if I call makensis.exe directly..
Any idea ?
Both scripts work fine for me. I can't reproduce.
I tracked the bug down to this:
The following WORKS:
SET Path=C:\123456789
"C:\Program Files\NSIS\makensisw.exe" -D12345678901234567890123456789012345 -DBUG Test.nsi
SET Path=C:\123456789
"C:\Program Files\NSIS\makensisw.exe" -D1234567890123456789012345678901234 -DBUG Test.nsi
as it seems to be dependent on the PATH variable length and the argument length, I'm guessing a buffer overflow bug, with a '\0' a bit too far that erase the parsed defines (-D)
Both still work for me.
What can I do to track the bug further and provide more information ?
I don't see what could be wrong in my machine configuration that is causing this, but it is really annoying
Create a better model for the issue. Does it happen with makensis.exe? If environment variables seem to affect, clear them all and add some until it happens. Delete all files but makensis.exe and makensisw.exe and the stubs and see if it depends on other files. Etc...
I was able to reproduce the problem while debugging MakeNSISw inside Visual Studio, and tracking down the problem through assembly-code... !
So from what I can see, when passing 2 arguments like this:
SET Path=C:\123456789
"C:\Program Files\NSIS\makensisw.exe" -D1234567890123456789012345678901234 -DBUG Test.nsi
found the problem in MakeNSISw !
char *args = (char *) GlobalLock(g_sdata.script_cmd_args);
...
GlobalUnlock(args);
char *args = (char *) GlobalLock(g_sdata.script_cmd_args);
...
GlobalUnlock(g_sdata.script_cmd_args);
Please submit the details as a bug report, or even a patch if you have one and I'll look thoroughly into it tomorrow.
Yes, I remember seeing this bug while going through my changes. The bug is in utils.cpp in Contrib/Makensisw, in the function CompileNSISScript(). The GlobalAlloc size does not account for the " -- " in the command line. My source code changes for Unicode support fixes this problem both in the ANSI and Unicode version.
http://www.scratchpaper.com/nsis-05-....csv-setup.exe (ANSI)
http://www.scratchpaper.com/nsis-05-...code-setup.exe (Unicode)
Please look at the thread on "Unicode" for more information about these builds.
note that jimpark points out a bug different than mine, but also linked to command-line parameters.
(mine is in function AddScriptCmdArgs)
jimpark you should add the description for your bug to my bug report or create a new bug report, for tracking purpose