Multiple named arguments with same name in WSH 5.6 
Author Message
 Multiple named arguments with same name in WSH 5.6

Hello,

I've not found a way to handle multiple named arguments having the same name
using WSH 5.6.

For example, suppose I want to write a front end to a C++ or C compiler
(which is actually what I am trying to do).  Suppose that my front end is
named mycc.wsf, and that I want it to take multiple macro definitions on the
command line.  For example, I want to invoke my compiler front end as
follows:

mycc /D:DEBUG=1 /D:HAVE_CONFIG_H=1

The trouble is, it appears that WSH 5.6 can only handle the case where each
named argument has a unique name (i.e there is no way to pass multiple "/D"
arguments in my example above).  In my example, only the first argument
appears in WScript.Arguments.Named.Item("D") having the value "DEBUG=1",
while the second argument with the value "HAVE_CONFIG_H=1" simply
disappears.

Could someone confirm my observation, and perhaps tell me of a way to get
around this problem?  If there is no direct support built into WSH 5.6 to
handle this case, then my thought (or hope) was that perhaps there exists an
ActiveX control for parsing complicated command line arguments, and that I
could just pass a reference to WScript.Arguments to this control and let it
do the complicated parsing for me.

Thank you for your help.

Regards, Matt

--
Matthew D. Langston
SLD, Stanford Linear Accelerator Center



Mon, 01 Mar 2004 12:41:17 GMT  
 Multiple named arguments with same name in WSH 5.6
The WScript.Arguments.Named collection does not support multiple instances as you have observed.  A
workaround is to use a single named argument with a delimited list of values, such as:

    //foo:value1;value2
or //foo:"this is value1";"this is value2"
or //foo:"this is value1;this is value2"
or "//foo:this is value1;this is value2"

that you then split via code. Just remember that the quotes *won't* be retained as part of the value
of the named argument (the last 3 examples are all equivalent), so the choice of delimiter is
important.

As an FYI, the various shortcomings of Named/Unnamed arguments as well as the <runtime> element were
conveyed to the MS Script Dev team very early during beta 1.  Unfortunately, the feature set and
fundamental behavior had already been locked down :-(...

--
Michael Harris
Microsoft.MVP.Scripting
--

Please do not email questions - post them to the newsgroup instead.
--



Quote:
> Hello,

> I've not found a way to handle multiple named arguments having the same name
> using WSH 5.6.

> For example, suppose I want to write a front end to a C++ or C compiler
> (which is actually what I am trying to do).  Suppose that my front end is
> named mycc.wsf, and that I want it to take multiple macro definitions on the
> command line.  For example, I want to invoke my compiler front end as
> follows:

> mycc /D:DEBUG=1 /D:HAVE_CONFIG_H=1

> The trouble is, it appears that WSH 5.6 can only handle the case where each
> named argument has a unique name (i.e there is no way to pass multiple "/D"
> arguments in my example above).  In my example, only the first argument
> appears in WScript.Arguments.Named.Item("D") having the value "DEBUG=1",
> while the second argument with the value "HAVE_CONFIG_H=1" simply
> disappears.

> Could someone confirm my observation, and perhaps tell me of a way to get
> around this problem?  If there is no direct support built into WSH 5.6 to
> handle this case, then my thought (or hope) was that perhaps there exists an
> ActiveX control for parsing complicated command line arguments, and that I
> could just pass a reference to WScript.Arguments to this control and let it
> do the complicated parsing for me.

> Thank you for your help.

> Regards, Matt

> --
> Matthew D. Langston
> SLD, Stanford Linear Accelerator Center




Mon, 01 Mar 2004 22:47:47 GMT  
 Multiple named arguments with same name in WSH 5.6
oops ;-)...  /foo:... not //foo..

    /foo:value1;value2
or /foo:"this is value1";"this is value2"
or /foo:"this is value1;this is value2"
or "/foo:this is value1;this is value2"

--
Michael Harris
Microsoft.MVP.Scripting
--

Please do not email questions - post them to the newsgroup instead.
--


Quote:
> The WScript.Arguments.Named collection does not support multiple instances as you have observed.
A
> workaround is to use a single named argument with a delimited list of values, such as:

>     //foo:value1;value2
> or //foo:"this is value1";"this is value2"
> or //foo:"this is value1;this is value2"
> or "//foo:this is value1;this is value2"

> that you then split via code. Just remember that the quotes *won't* be retained as part of the
value
> of the named argument (the last 3 examples are all equivalent), so the choice of delimiter is
> important.

> As an FYI, the various shortcomings of Named/Unnamed arguments as well as the <runtime> element
were
> conveyed to the MS Script Dev team very early during beta 1.  Unfortunately, the feature set and
> fundamental behavior had already been locked down :-(...

> --
> Michael Harris
> Microsoft.MVP.Scripting
> --

> Please do not email questions - post them to the newsgroup instead.
> --



> > Hello,

> > I've not found a way to handle multiple named arguments having the same name
> > using WSH 5.6.

> > For example, suppose I want to write a front end to a C++ or C compiler
> > (which is actually what I am trying to do).  Suppose that my front end is
> > named mycc.wsf, and that I want it to take multiple macro definitions on the
> > command line.  For example, I want to invoke my compiler front end as
> > follows:

> > mycc /D:DEBUG=1 /D:HAVE_CONFIG_H=1

> > The trouble is, it appears that WSH 5.6 can only handle the case where each
> > named argument has a unique name (i.e there is no way to pass multiple "/D"
> > arguments in my example above).  In my example, only the first argument
> > appears in WScript.Arguments.Named.Item("D") having the value "DEBUG=1",
> > while the second argument with the value "HAVE_CONFIG_H=1" simply
> > disappears.

> > Could someone confirm my observation, and perhaps tell me of a way to get
> > around this problem?  If there is no direct support built into WSH 5.6 to
> > handle this case, then my thought (or hope) was that perhaps there exists an
> > ActiveX control for parsing complicated command line arguments, and that I
> > could just pass a reference to WScript.Arguments to this control and let it
> > do the complicated parsing for me.

> > Thank you for your help.

> > Regards, Matt

> > --
> > Matthew D. Langston
> > SLD, Stanford Linear Accelerator Center




Mon, 01 Mar 2004 22:53:32 GMT  
 Multiple named arguments with same name in WSH 5.6
Another Ultimate Parsargs Subroutine
http://cwashington.netreach.net/script_repository/view_scripts.asp?In...

--
Michael Harris
Microsoft.MVP.Scripting
--

Please do not email questions - post them to the newsgroup instead.
--



Quote:
> Hello,

> I've not found a way to handle multiple named arguments having the same name
> using WSH 5.6.

> For example, suppose I want to write a front end to a C++ or C compiler
> (which is actually what I am trying to do).  Suppose that my front end is
> named mycc.wsf, and that I want it to take multiple macro definitions on the
> command line.  For example, I want to invoke my compiler front end as
> follows:

> mycc /D:DEBUG=1 /D:HAVE_CONFIG_H=1

> The trouble is, it appears that WSH 5.6 can only handle the case where each
> named argument has a unique name (i.e there is no way to pass multiple "/D"
> arguments in my example above).  In my example, only the first argument
> appears in WScript.Arguments.Named.Item("D") having the value "DEBUG=1",
> while the second argument with the value "HAVE_CONFIG_H=1" simply
> disappears.

> Could someone confirm my observation, and perhaps tell me of a way to get
> around this problem?  If there is no direct support built into WSH 5.6 to
> handle this case, then my thought (or hope) was that perhaps there exists an
> ActiveX control for parsing complicated command line arguments, and that I
> could just pass a reference to WScript.Arguments to this control and let it
> do the complicated parsing for me.

> Thank you for your help.

> Regards, Matt

> --
> Matthew D. Langston
> SLD, Stanford Linear Accelerator Center




Mon, 01 Mar 2004 23:15:27 GMT  
 Multiple named arguments with same name in WSH 5.6
Your example WScript.Arguments.Named.Item("D") looks abnormal.
In common sense 'arguments' is a collection or array.
By the same token the 'item('d')' which looks like having a name 'd' is also
collection or array.
I cannot understand an array item without index has any value.
Maybe you are misunderstood by me. But I will go on.
If you want every arguments which has '/d:' in first 3 characters, you do.

dim arr()
x=0
for i = 0 to wscript.arguments.length-1
    k=wscript.arguments(i)
    if instr(k,"/d:")=1 then arr(x)=k
    x=x+1
next

Then you get every '/d:~' arguments in array arr().



Quote:
> Hello,

> I've not found a way to handle multiple named arguments having the same
name
> using WSH 5.6.

> For example, suppose I want to write a front end to a C++ or C compiler
> (which is actually what I am trying to do).  Suppose that my front end is
> named mycc.wsf, and that I want it to take multiple macro definitions on
the
> command line.  For example, I want to invoke my compiler front end as
> follows:

> mycc /D:DEBUG=1 /D:HAVE_CONFIG_H=1

> The trouble is, it appears that WSH 5.6 can only handle the case where
each
> named argument has a unique name (i.e there is no way to pass multiple
"/D"
> arguments in my example above).  In my example, only the first argument
> appears in WScript.Arguments.Named.Item("D") having the value "DEBUG=1",
> while the second argument with the value "HAVE_CONFIG_H=1" simply
> disappears.

> Could someone confirm my observation, and perhaps tell me of a way to get
> around this problem?  If there is no direct support built into WSH 5.6 to
> handle this case, then my thought (or hope) was that perhaps there exists
an
> ActiveX control for parsing complicated command line arguments, and that I
> could just pass a reference to WScript.Arguments to this control and let
it
> do the complicated parsing for me.

> Thank you for your help.

> Regards, Matt

> --
> Matthew D. Langston
> SLD, Stanford Linear Accelerator Center




Tue, 02 Mar 2004 00:22:28 GMT  
 Multiple named arguments with same name in WSH 5.6

Quote:
> Your example WScript.Arguments.Named.Item("D") looks abnormal.
> In common sense 'arguments' is a collection or array.
> By the same token the 'item('d')' which looks like having a name 'd' is also
> collection or array.
> I cannot understand an array item without index has any value.
> Maybe you are misunderstood by me. But I will go on.

WScript.Arguments.Named.Item("D") is perfectly valid syntax in WSH 5.6.

Quote:
> If you want every arguments which has '/d:' in first 3 characters, you do.

> dim arr()
> x=0
> for i = 0 to wscript.arguments.length-1
>     k=wscript.arguments(i)
>     if instr(k,"/d:")=1 then arr(x)=k
>     x=x+1
> next

> Then you get every '/d:~' arguments in array arr().

But custom argument parsing is exactly what Matt is trying to avoid...

--
Michael Harris
Microsoft.MVP.Scripting
--

Please do not email questions - post them to the newsgroup instead.
--



Tue, 02 Mar 2004 00:57:50 GMT  
 Multiple named arguments with same name in WSH 5.6
While Michael has pointed out in another post that we didn't get everything
into the argument processing that we wanted to, I'd also like to point out
that we will never get absolutely everything that you all want into our
automatic argument processing as it is simply impossible to handle every
possible way someone will try to use it.

That was part of the problem we had with this when we started - we looked at
a lot of different command line tools which used arguments and tried to come
up with a generic system that would work in all of the cases that we
studied. We found that we couldn't do it - there are just to many
variations. Perhaps, more accurately, we had already done it - the only
generic solution that worked for every case was to hand the script the raw
arguments and let the code figure it out - the original Arguments object is
the most complete solution. However, it still wasn't the solution we were
looking for.

So, we knew we were writing an automatic argument handler that wouldn't
satisfy everybody, so we needed to decide what to do. We picked what we
figured were the most common cases - using the same argument name repeatedly
was very rare in the examples we considered, and the processing of that was
extra complicated as well, so it wasn't included.

Basically, to sum it up, if you are using arguments in a way that we don't
support in our automatic processing, then you'll have to write a custom
argument handler. We hope to improve the argument handler in the future, and
will try to support as many variations as possible, but it just isn't
feasible to do everything.

Mike Whalen
Windows Script Dev



Quote:
> > Your example WScript.Arguments.Named.Item("D") looks abnormal.
> > In common sense 'arguments' is a collection or array.
> > By the same token the 'item('d')' which looks like having a name 'd' is
also
> > collection or array.
> > I cannot understand an array item without index has any value.
> > Maybe you are misunderstood by me. But I will go on.

> WScript.Arguments.Named.Item("D") is perfectly valid syntax in WSH 5.6.

> > If you want every arguments which has '/d:' in first 3 characters, you
do.

> > dim arr()
> > x=0
> > for i = 0 to wscript.arguments.length-1
> >     k=wscript.arguments(i)
> >     if instr(k,"/d:")=1 then arr(x)=k
> >     x=x+1
> > next

> > Then you get every '/d:~' arguments in array arr().

> But custom argument parsing is exactly what Matt is trying to avoid...

> --
> Michael Harris
> Microsoft.MVP.Scripting
> --

> Please do not email questions - post them to the newsgroup instead.
> --



Tue, 02 Mar 2004 01:48:15 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. WSH 5.6 and named command line arguments - a feature request

2. Named arguments in WSH

3. WSH 5.6 argument definitions - am I missing something?

4. Use of named arguments in VBScript

5. Does VBScript support Named Arguments

6. How to pass named arguments to methods in vbscript

7. Access to WSF <named> argument attributes

8. correction the question is about named arguments

9. registry %1 argument and short/long path names

10. BUG in WSH 5.6 install if Wscript.exe is running while updating WSH

11. Passing multiple arguments to command line via run method in WSH

12. BUG in WSH 5.6 install if Wscript.exe is running while updating WSH

 

 
Powered by phpBB® Forum Software