Why stripping " from cmdline[]?

[HighGuy]

Wasn't sure if I should put this to the Bug Reports, so I decided to hear your opinion first. The help file says:

----------------------------------------------------------

So if your script is run like this:

AutoIt3.exe myscript.au3 param1 "this is another param"

$CmdLine[0] equals... 2

$CmdLine[1] equals... param1

$CmdLine[2] equals... this is another param

----------------------------------------------------------

I'm asking myself why " ist stripped from "this is another param"? If using paths to files or directories as parameters these " are absolutely necessary! What do you think? Shouldn't $CmdLine[2] equals to "this is another param"?

[Chris_1013]

Hmmm, tricky one. Because, the speakmarks are there as there is a space in the parameters, but I don't think most Windows programs would treat the speech marks as being part of the parameter. They should show up in the $CmdLineRaw variable though.

[Owen]

I dont think AutoIt has that option

I think Windows handles that part - As every app takes them like that.

[therks]

As much as I prefer not having the quotations in the variable, I feel the need to point out that batch files will include the symbols.

tmp.bat:

@echo off
echo.
echo %1

C:\>tmp.bat Hello world

Hello

C:\>tmp.bat "Hello world"

"Hello world"

C:\>

[Chris_1013]

I dont think AutoIt has that option

I think Windows handles that part - As every app takes them like that.

<{POST_SNAPBACK}>

What option? If you're talking about the $CmdLineRaw variable it was probably only added recently. Go download 3.1 now it's available.

[HighGuy]

Let's give an example why I ran into trouble with this.

Suppose you have the following funtion in a program MyRun.exe:

Func MyRun($sProg, $sParam)
  RunWait($sProg & " " & $sParam)
EndFunc

You can start MyRun.exe the following:

MyRun.exe "C:\path to dir\prog.exe" "C:\Path to file\file.dat" [more params]

MyRun will read the parameters and call the function MyRun() with them.

If you strip the quotes MyRun() will not work. You might suppose to quote $sProg and $sParam in MyRun(), but this is not a solution, because you can't be sure that $sParam is always a path to a file. It can also be something like /param1 /param2 and that's totally different from "/param1 /param2"! Got it?

[Chris_1013]

Yeah, i "got it"...

I wasn't saying that there wasn't necessarily a problem with the way AutoIt works, mearly explaining I wouldn't expect this was a bug, but as deisgned, because I believe this is the way most Windows programs work. I suppose even splitting up the $CmdLineRaw variable would be tricky as you may have spaces in params. Surely it's better practice to use some character before parameters to indicate they are parameters. I know some programs will take (for example)

my.exe "file to open.ext"

But, ususally, in my experience when you have multiple parameters you have a slash or a dash or something before them, because then this allows for the parameters to be in any order and you know what they are. i.e;

my.exe /f:"file to open.ext" ... other options here

[HighGuy]

... because I believe this is the way most Windows programs work. I

Do you have examples? What about other programming languages? Does anybody know how they handle quotes in parameters?

But, ususally, in my experience when you have multiple parameters you have a slash or a dash or something before them, because then this allows for the parameters to be in any order and you know what they are. i.e;

my.exe /f:"file to open.ext" ... other options here

<{POST_SNAPBACK}>

and even these quotes will be deleted! Thus the param /f:"file to open.ext" will give you $cmdline[1] = /f:file to open.ext

In my opinion that's not o.k. because it's in the responsibility of the user to start the program with correctly formated params and not me to guess if he used quotes or not. But if I'm the only one complaining about it, I will look for a work around in my case and surrender to the opinion of the majority.

[SlimShady]

Do you have examples? What about other programming languages? Does anybody know how they handle quotes in parameters?

and even these quotes will be deleted! Thus the param /f:"file to open.ext" will give you $cmdline[1] = /f:file to open.ext

In my opinion that's not o.k. because it's in the responsibility of the user to start the program with correctly formated params and not me to guess if he used quotes or not. But if I'm the only one complaining about it, I will look for a work around in my case and surrender to the opinion of the majority.

<{POST_SNAPBACK}>

I see what you mean. I wonder too why quotes are stripped by default.

Jon said something about this, a while ago.

I'm gonna search...

[Valik]

Is it so terribly hard to build a new string like this:

Local $sParams = ""
For $i = 1 To $CmdLine[0]
    If StringInStr($CmdLine[$i], " ") Then
        $sParams = $sParams & ' "' & $CmdLine[$i] & '"'
    Else
        $sParams = $sParams & " " & $CmdLine[$i]
    EndIf
Next

If you're going to write a wrapper application, then expect a little work. Don't be too lazy to do your own handling. Applications are designed to get their input in an easy to use format for them, not for passing along to another application. If thats your goal, then do some work.

[HighGuy]

If you're going to write a wrapper application, then expect a little work.

<{POST_SNAPBACK}>

Maybe I'm lazy, but it would need a lot of code in the wrapper to take all possible cases for parameters into consideration.

Folks, give me one good reason/example why it's absolutely necessary to strip of quotes! I don't want my programmer life to be as complex as it can be just because it's hip.

[SlimShady]

@Valik

See the following example.

That's why I agree that quotes should NOT be stripped by default.

If the change is too big, add an option: Opt("CmdLineQuotes", 1)

MsgBox(64, "Test", "$CmdLineRaw = " & $CmdLineRaw)

If $CmdLine[0] Then
   For $i = 1 To $CmdLine[0]
      MsgBox(64, "Test", "$CmdLine[" & $i & "] = " & $CmdLine[$i])
   Next
EndIf

[Valik]

Maybe I'm lazy, but it would need a lot of code in the wrapper to take all possible cases for parameters into consideration.

Folks, give me one good reason/example why it's absolutely necessary to strip of quotes! I don't want my programmer life to be as complex as it can be just because it's hip.

<{POST_SNAPBACK}>

Wait, are you just bitching for the sake of arguing now? I just tested $CmdLineRaw and as mentioned earlier, it doesn't strip quotes. I also provided you a reason why they should be stripped. Most of the time you want the quotes stripped because you aren't forwarding them along to another program. I for one don't want to have to strip quotes off parameters in all my scripts that aren't wrappers. And lastly, I even provided some simple code to re-add quotes (For the most part). I fail to see why you aren't using at least one of those solutions. $CmdLineRaw appears to me to be the "Do all the work for me because I'm too lazy" route you're looking for.

[Jos]

Heres how VBscript handles commandline params (Tested on Winxp)....

Save below code as demo.vbs

Option Explicit
Dim k, args, oShell
Set args = WScript.Arguments
WScript.echo("Parameters:" )
for k = 0 to args.Count - 1
   WScript.echo(args.Item(k))
next
Set args = Nothing

goto cmd prompt and type: cscript demo.vbs "1 2" 3 4

Result:

Parameters:

1 2

3

4

So looks pretty similar to the way AutoIt does it.

[Valik]

@Valik

See the following example.

That's why I agree that quotes should NOT be stripped by default.

If the change is too big, add an option: Opt("CmdLineQuotes", 1)

MsgBox(64, "Test", "$CmdLineRaw = " & $CmdLineRaw)

If $CmdLine[0] Then
   For $i = 1 To $CmdLine[0]
      MsgBox(64, "Test", "$CmdLine[" & $i & "] = " & $CmdLine[$i])
   Next
EndIf

<{POST_SNAPBACK}>

Bad idea. Take this innocent (And not so uncommon code):

$bFound = 0
For $i = 1 To $CmdLine[0]
    If $CmdLine[$i] = "/param" Then $bFound = 1
Next
MsgBox(4096, "", $bFound)

If (For the sake of argument), quotes aren't stripped:

RunScript.exe /param

Good, that works no problem.

RunScript.exe "/param"

BOOM. Code no worky.

If quotes are kept, then you have to write:

$bFound = 0
For $i = 1 To $CmdLine[0]
    If StringReplace($CmdLine[$i], '"', "") = "/param" Then $bFound = 1
Next
MsgBox(4096, "", $bFound)

Now which makes sense? Having the parameters in a stripped format which is easy to work with as far as the current script is concerned. Or having the parameters in a difficult format to work with, but easy to forward along to Run/RunWait.

I've wrote a lot of scripts that do one or the other or both and I've not had a problem with how quotes are stripped.

[SlimShady]

I forgot to tell what I used as an example argument.

I used the argument: Hulk"Hollywood"Hogan

It doesn't matter to me anyways. I haven't bumped (yet) into these issues.

Edited February 9, 2005 by SlimShady

[HighGuy]

If quotes are kept, then you have to write:

$bFound = 0
For $i = 1 To $CmdLine[0]
    If StringReplace($CmdLine[$i], '"', "") = "/param" Then $bFound = 1
Next
MsgBox(4096, "", $bFound)

Now which makes sense?  Having the parameters in a stripped format which is easy to work with as far as the current script is concerned.  Or having the parameters in a difficult format to work with, but easy to forward along to Run/RunWait.

<{POST_SNAPBACK}>

O.k. this is what I wanted to read and I can see now which problems it may leed to not stripping quotes (especially if you use these unstripped parameters in internal AutoIt-functions).

Thank you JdeB for giving an example in VBS, thank you Valik for showing the problematic part of this change request.

Is there anything against SlimShadys suggestion adding an option of Opt("CmdLineQuotes", 1)?