byteboon
1st October 2004 18:08 UTC

BUG: GetParameters or $CMDLINE broken in 2.01
Hi,

I have an uninstall script that takes a custom parameter. After upgrading to 2.01, this script now fails to recognize the parameter. It seems that the GetParameters or $CMDLINE behaviour changed. I now get a trailing space in the returned string from GetParameters, which fails my StrCmp. I know I can add a space to my string, but this should be fixed internally if it is indeed a bug.

Thanks,
Jeremy.


MY Code:

Function un.onInit
SetSilent silent

StrCpy $R0 ""
Call un.GetParameters
Pop $R0

MessageBox MB_OK "[$R0]" ; this shows [/D ]

StrCmp $R0 "/D" 0 GoCheckParm2 ; fails now because "/D"!="/D "
..do stuff..
GoCheckParm2:
..do stuff..

...snip...

Function un.GetParameters

Push $R0
Push $R1
Push $R2
Push $R3

StrCpy $R2 1
StrLen $R3 $CMDLINE

;Check for quote or space
StrCpy $R0 $CMDLINE $R2
StrCmp $R0 '"' 0 +3
StrCpy $R1 '"'
Goto loop
StrCpy $R1 " "

loop:
IntOp $R2 $R2 + 1
StrCpy $R0 $CMDLINE 1 $R2
StrCmp $R0 $R1 get
StrCmp $R2 $R3 get
Goto loop

get:
IntOp $R2 $R2 + 1
StrCpy $R0 $CMDLINE 1 $R2
StrCmp $R0 " " get
StrCpy $R0 $CMDLINE "" $R2

Pop $R3
Pop $R2
Pop $R1
Exch $R0

FunctionEnd

kichik
1st October 2004 21:08 UTC

It's $CMDLINE's behavior that changed in version 2.0. It's "made the command line parser cut right on /D= and _?= and not one char before. this way foo.exe "bla"/D=..., which appears to be valid in other applications, will not get the last quote cut off."

Should $CMDLINE stick to the real command line or trim from the right? GetParameters already trims from the left, maybe it should trim from the right too. The uninstaller should remove the space it adds, that's what it has been doing before 2.0. But should it trim other spaces too? Someone might want to use the spaces for some reason.

Comments anyone?

byteboon
1st October 2004 22:13 UTC

Obviously I'm biased since I want my code to work like it did before but...

I tend to think of the commandline like the C main(argc,argv[]) where a space in a non-quoted part of the commandline is treated as a delimiter for a new parameter. I understand that Windows just passes the whole line, but is it not reasonable to mimic C's behaviour? Even Windows requires a path with a space be quoted to be recognized properly. So, if I want a trailing space, I could use mycmd.exe "/D " to force the space... usually you don't want the quotes returned with the parameter, and if quotes are important you can double quote...

This is how I would naturally expect things to be parsed:

mycmd.exe /D -> [/D]
mycmd.exe "/D " -> [/D ]
mycmd.exe /D=test -> [/D=test]
mycmd.exe "/D=test -> [/D=test]
mycmd.exe /D="test " -> [/D="test "]
mycmd.exe ""/D " " -> ["/D " ] (but I guess parsing double quotes could get hairy)

My two cents.

kichik
1st October 2004 22:21 UTC

It's all true, but $CMDLINE doesn't pretend to mimic C's behavior. It just passes the command line almost as-is.

Anyway, I have reverted the changes done in 1.54 and added a check to make sure there is a space before _=? and /D=. This will cause your script to work as before.

Currnetly, $CMDLINE is not trimmed. It just passes the arguments the user passed as-is.

byteboon
1st October 2004 22:23 UTC

Works for me, thanks for a great product! :D

byteboon
3rd October 2004 02:15 UTC

Well, I tried the autogenerated build from Saturday and the same problem exists. I still get a trailing space as above. Am I missing something?

Please not that this is *not* the /D= switch for the compiler, this is my own /D switch that I use to tell the uninstaller to do something different.

kichik
10th October 2004 14:38 UTC

You are missing a compiled version ;)