Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > microsoft.public.scripting.vbscript > #12094 > unrolled thread

Trick to know whether a command line parameter is quoted or not?

Back to article view | Back to microsoft.public.scripting.vbscript

Contents

  Trick to know whether a command line parameter is quoted or not? JJ <jj4public@vfemail.net> - 2019-04-21 19:17 +0700
    Re: Trick to know whether a command line parameter is quoted or not? "R.Wieser" <address@not.available> - 2019-04-21 15:34 +0200
      Re: Trick to know whether a command line parameter is quoted or not? "R.Wieser" <address@not.available> - 2019-04-21 15:39 +0200
      Re: Trick to know whether a command line parameter is quoted or not? JJ <jj4public@vfemail.net> - 2019-04-22 19:07 +0700
        Re: Trick to know whether a command line parameter is quoted or not? "R.Wieser" <address@not.available> - 2019-04-22 15:37 +0200
          Re: Trick to know whether a command line parameter is quoted or not? JJ <jj4public@vfemail.net> - 2019-04-23 22:51 +0700
    Re: Trick to know whether a command line parameter is quoted or not? "Mayayana" <mayayana@invalid.nospam> - 2019-04-21 10:09 -0400
      Re: Trick to know whether a command line parameter is quoted or not? JJ <jj4public@vfemail.net> - 2019-04-22 19:08 +0700
    Re: Trick to know whether a command line parameter is quoted or not? "Mayayana" <mayayana@invalid.nospam> - 2019-04-22 08:53 -0400

#12094 — Trick to know whether a command line parameter is quoted or not?

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.

[toc] | [next] | [standalone]

#12096

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 ...

> 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 

[toc] | [prev] | [next] | [standalone]

#12097

JJ,

> 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

[toc] | [prev] | [next] | [standalone]

#12099

On Sun, 21 Apr 2019 15:34:31 +0200, R.Wieser wrote:

> 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 ...
> 
>> 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.

[toc] | [prev] | [next] | [standalone]

#12102

JJ,

>>> parameter #2 would be different from the program
>>> because it's not double-quoted.
...
> 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.

> 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 ...

> 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

[toc] | [prev] | [next] | [standalone]

#12103

On Mon, 22 Apr 2019 15:37:30 +0200, R.Wieser wrote:
> 
> 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

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.

[toc] | [prev] | [next] | [standalone]

#12098

"JJ" <jj4public@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. 

[toc] | [prev] | [next] | [standalone]

#12100

On Sun, 21 Apr 2019 10:09:15 -0400, Mayayana wrote:
> 
>   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.

Unfortunately, the program is not mine.

[toc] | [prev] | [next] | [standalone]

#12101

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

[toc] | [prev] | [standalone]

Back to top | Article view | microsoft.public.scripting.vbscript

csiph-web