Discussion:
Trick to know whether a command line parameter is quoted or not?
(too old to reply)
JJ
2019-04-21 12:17:31 UTC
Permalink
I have a program where it differentiates its parameters based on whether a
parameter is double-quoted or not, and I need to make a launcher script for
it.

The problem is that WshArguments object strips any double-quote enclosures
from the parsed parameters, and there seem to be a way to know whether a
parameter was originally double-quoted or not in the command line. e.g. when
the command line is like below.

launcher.vbs abc "def ghi" "jkl"

Parameter #0 is: abc
Parameter #1 is: def ghi
Parameter #2 is: jkl

In this case, the meaning of parameter #2 would be different from the
program because it's not double-quoted. So, I can't pass it to the program
as is.

So, is there a trick to get the parameters without their double-quote
enclosures stripped out? Or get the whole original unparsed command line? So
that I can manually parse it.

I thought about using WMI to retrieve the whole command line, but I haven't
found a reliable way to uniquely identify the current script's process, for
use in the WMI query.
R.Wieser
2019-04-21 13:34:31 UTC
Permalink
JJ,
Post by JJ
In this case, the meaning of parameter #2 would be different
from the program because it's not double-quoted.
I'm assuming you ment #0 there ...
Post by JJ
So, I can't pass it to the program as is.
Why not ? It /is/ a string in VBScript. Could it be regarded as
anything else ?

You could get into trouble with an argument like "123" (including the
double-quotes this time), as its would be a number without those
double-quotes, but now a string instead.

In this case (number/string confusion) you could try and see if the
'vartype' or 'typename' functions could be of help.

And maybe also take a peek at named arguments (the "/x:y" form)

Regards,
Rudy Wieser
R.Wieser
2019-04-21 13:39:41 UTC
Permalink
JJ,
Post by R.Wieser
In this case (number/string confusion) you could try and see if the
'vartype' or 'typename' functions could be of help.
You can forget about that I'm afraid: :-( All arguments (raw, named and
unnamed alike) are regarded as strings, even when numbers are entered.

Regards
Rudy Wieser
JJ
2019-04-22 12:07:27 UTC
Permalink
Post by R.Wieser
JJ,
Post by JJ
In this case, the meaning of parameter #2 would be different
from the program because it's not double-quoted.
I'm assuming you ment #0 there ...
Post by JJ
So, I can't pass it to the program as is.
Why not ? It /is/ a string in VBScript. Could it be regarded as
anything else ?
You could get into trouble with an argument like "123" (including the
double-quotes this time), as its would be a number without those
double-quotes, but now a string instead.
In this case (number/string confusion) you could try and see if the
'vartype' or 'typename' functions could be of help.
And maybe also take a peek at named arguments (the "/x:y" form)
No. It's not #0. It's #2.

Based on the original command line:
Parameter #0: abc
Parameter #1: "def ghi"
Parameter #2: "jkl"

But WshArgument can only see:
Parameter #0: abc
Parameter #1: def ghi
Parameter #2: jkl

Because #1 has a space in it, it means that the original parameter is
quoted, so I could restore that to: "def ghi"

But I have no way to know whether #2 was originally passed with quote or
not.
R.Wieser
2019-04-22 13:37:30 UTC
Permalink
JJ,
Post by JJ
parameter #2 would be different from the program
because it's not double-quoted.
...
Post by JJ
No. It's not #0. It's #2.
My apologies. I thought you where referring to the origionals. Also, with
nothing said further, both #1 and #2 became unquoted in the end result, so I
ruled them out.
Post by JJ
Because #1 has a space in it, it means that the original parameter
is quoted, so I could restore that to: "def ghi"
I would be careful there: you've found one character that indcates that it
was origionally quoted, but there are more ...
Post by JJ
But I have no way to know whether #2 was originally passed
with quote or not.
It certainly looks that way.

There seems to be a kind of solution using WMI though (not very clean):
https://stackoverflow.com/questions/40056204/how-do-i-get-raw-vbscript-command-line-arguments

The only other solution seems to be to add another object, just to
encapsulate the GetCommandLine function (Kernel32).

Regards,
Rudy Wieser
JJ
2019-04-23 15:51:21 UTC
Permalink
Post by R.Wieser
https://stackoverflow.com/questions/40056204/how-do-i-get-raw-vbscript-command-line-arguments
Yes, WMI is one possible solution. But it's not reliable when there are two
separate instances of the script. There doesn't seem to be a way to indicate
which is which. i.e. Script#1 may end up getting the command line of
Script#2, or vice versa.

Mayayana
2019-04-21 14:09:15 UTC
Permalink
"JJ" <***@vfemail.net> wrote

| The problem is that WshArguments object strips any double-quote enclosures
| from the parsed parameters, and there seem to be a way to know whether a
| parameter was originally double-quoted or not in the command line. e.g.
when
| the command line is like below.

Not a direct answer, but if it were me I'd use
markers. (This assumes the target program is your own.)
For instance, I have a CAB component with a function
to add files to the CAB. The method takes a pipe-delimited
string. Another option is to use options or switches:
/i C:\windows\desktop\file with spaces.txt /o C:\file2 with spaces.txt

Both methods provide unambiguous input without quotes.

That's also easier for the sender, rather than struggling
with multiple, nested quotes.
JJ
2019-04-22 12:08:59 UTC
Permalink
Post by Mayayana
Not a direct answer, but if it were me I'd use
markers. (This assumes the target program is your own.)
For instance, I have a CAB component with a function
to add files to the CAB. The method takes a pipe-delimited
/i C:\windows\desktop\file with spaces.txt /o C:\file2 with spaces.txt
Both methods provide unambiguous input without quotes.
That's also easier for the sender, rather than struggling
with multiple, nested quotes.
Unfortunately, the program is not mine.
Mayayana
2019-04-22 12:53:56 UTC
Permalink
This works for me, even though it's a pain in the neck:

Dim SH, Qt
Set SH = CreateObject("WScript.Shell")
Qt = Chr(34)
SH.Run "C:\windows\desktop\testcom.exe abc " & Qt & "def ghi" & Qt & " " &
Qt & "abc" & Qt
Set SH = Nothing

I wrote a VB program to test it. testcom.exe contains
only:

Sub Form_Load()
Dim sCom as string
sCom = Command()
MsgBox sCom
Unload Me
End Sub
Continue reading on narkive:
Loading...