WSH 5.6 argument definitions - am I missing something?
| Author |
Message |
|
Paul Moor
#1 / 8
|
 WSH 5.6 argument definitions - am I missing something? Take the following file, x.wsf <job>
<runtime>
<named name="file" helpstring="the file"
required="true" type="string"/>
</runtime>
<script language="VBScript">
WScript.Echo WScript.Arguments.Named("file")
</script>
</job>
Now type
cscript x.wsf
No problem, no error, output is empty.
But argument file has required="true". Why didn't I get an error?
Equally, "cscript x.wsf /file" gives no error, even though /file is
specified, but no value is specified...
Surely the argument definitions should be respected?
Paul.
|
| Sat, 07 Jun 2003 05:18:37 GMT |
|
 |
|
MS
#2 / 8
|
WSH 5.6 argument definitions - am I missing something? I figured this would confuse some people, but that isn't how the arguments
elements work at this time. We may add that in argument validation in the
future, but there was a fundamental design problem that we didn't find a
workaround for in time (we could have completely rewrote the code
involved... that's a bit more than we could do), so we decided to go with
just usage formatting and no validation. The attributes that you set for the
descriptions of the arguments are used only in setting up the usage
information. For instance, if you set "required" as false, then when you
show usage, there will be brackets around the argument, like:
"[file:string]". All of the other attributes are there for that purpose as
well - just for formatting the usage. Note: to show usage, either call
Arguments.ShowUsage or run the script with the /? argument.
Mike Whalen
Windows Script Dev
Quote: > Take the following file, x.wsf > <job>
> <runtime>
> <named name="file" helpstring="the file"
> required="true" type="string"/>
> </runtime>
> <script language="VBScript">
> WScript.Echo WScript.Arguments.Named("file")
> </script>
> </job>
> Now type
> cscript x.wsf
> No problem, no error, output is empty.
> But argument file has required="true". Why didn't I get an error?
> Equally, "cscript x.wsf /file" gives no error, even though /file is
> specified, but no value is specified...
> Surely the argument definitions should be respected?
> Paul.
|
| Sat, 07 Jun 2003 05:42:29 GMT |
|
|
|
Mark
#3 / 8
|
WSH 5.6 argument definitions - am I missing something? try wscript.arguments.named.item("file")
Quote: > Take the following file, x.wsf > <job>
> <runtime>
> <named name="file" helpstring="the file"
> required="true" type="string"/>
> </runtime>
> <script language="VBScript">
> WScript.Echo WScript.Arguments.Named("file")
> </script>
> </job>
> Now type
> cscript x.wsf
> No problem, no error, output is empty.
> But argument file has required="true". Why didn't I get an error?
> Equally, "cscript x.wsf /file" gives no error, even though /file is
> specified, but no value is specified...
> Surely the argument definitions should be respected?
> Paul.
|
| Sat, 07 Jun 2003 05:59:18 GMT |
|
|
|
Michael Harri
#4 / 8
|
WSH 5.6 argument definitions - am I missing something? To expand a bit on what Mike Whalen posted, use the ...Named.Exists() method for validation. <job>
<runtime>
<named name="file" helpstring="the file"
required="true" type="string"/>
</runtime>
<script language="VBScript">
With WScript.Arguments
If .Named.Exists("file") Then
WScript.Echo .Named.Item("file")
Else
WScript.Echo "file argument is missing"
WScript.Echo
.ShowUsage
End If
End With
</script>
</job>
--
Michael Harris
Microsoft.MVP.Scripting
--
Please do not email questions - post them to the newsgroup instead.
--
Quote: > Take the following file, x.wsf > <job>
> <runtime>
> <named name="file" helpstring="the file"
> required="true" type="string"/>
> </runtime>
> <script language="VBScript">
> WScript.Echo WScript.Arguments.Named("file")
> </script>
> </job>
> Now type
> cscript x.wsf
> No problem, no error, output is empty.
> But argument file has required="true". Why didn't I get an error?
> Equally, "cscript x.wsf /file" gives no error, even though /file is
> specified, but no value is specified...
> Surely the argument definitions should be respected?
> Paul.
|
| Sat, 07 Jun 2003 10:20:42 GMT |
|
|
|
Paul Moor
#5 / 8
|
WSH 5.6 argument definitions - am I missing something? On Mon, 18 Dec 2000 22:42:29 +0100, "Mike Whalen \(MS\)" Quote:
>I figured this would confuse some people, but that isn't how the arguments
>elements work at this time. We may add that in argument validation in the
>future, but there was a fundamental design problem that we didn't find a
>workaround for in time (we could have completely rewrote the code
>involved... that's a bit more than we could do), so we decided to go with
>just usage formatting and no validation.
Blech. That's definitely not what I was hoping for. Without the validation aspect, this feature isn't very attractive - not least because I don't really like the argument format (why /file:xxx and not /file xxx?) So far, 5.6 isn't looking as good as I'd hoped...
Paul.
|
| Sat, 07 Jun 2003 21:18:24 GMT |
|
|
|
Jim de Graf
#6 / 8
|
WSH 5.6 argument definitions - am I missing something? If the syntax was /file xxx
instead of
/file:xxx
then how would the handler know whether xxx belonged to the /file parameter
or was an unnamed argument and you just forgot to enter the /file value? You
have
to have a way of binding the named argument to the name itself that is
unambiguous.
Quote: > On Mon, 18 Dec 2000 22:42:29 +0100, "Mike Whalen \(MS\)"
> >I figured this would confuse some people, but that isn't how the
arguments
> >elements work at this time. We may add that in argument validation in the
> >future, but there was a fundamental design problem that we didn't find a
> >workaround for in time (we could have completely rewrote the code
> >involved... that's a bit more than we could do), so we decided to go with
> >just usage formatting and no validation.
> Blech. That's definitely not what I was hoping for. Without the
> validation aspect, this feature isn't very attractive - not least
> because I don't really like the argument format (why /file:xxx and not
> /file xxx?)
> So far, 5.6 isn't looking as good as I'd hoped...
> Paul.
|
| Mon, 09 Jun 2003 16:32:33 GMT |
|
|
|
Paul Moor
#7 / 8
|
WSH 5.6 argument definitions - am I missing something? On Thu, 21 Dec 2000 02:32:33 -0600, "Jim de Graff" Quote:
>If the syntax was > /file xxx
>instead of
> /file:xxx
>then how would the handler know whether xxx belonged to the /file parameter
>or was an unnamed argument and you just forgot to enter the /file value? You
>have to have a way of binding the named argument to the name itself that is
>unambiguous.
To be blunt - just like every other command line program I have ever seen... (Specifically, /file xxx is always an argument to /file.) Paul
|
| Wed, 11 Jun 2003 04:33:25 GMT |
|
|
|
Steve Fulto
#8 / 8
|
WSH 5.6 argument definitions - am I missing something?
Quote: > On Thu, 21 Dec 2000 02:32:33 -0600, "Jim de Graff"
> >If the syntax was
> > /file xxx
> >instead of
> > /file:xxx
> >then how would the handler know whether xxx belonged to the /file
parameter
> >or was an unnamed argument and you just forgot to enter the /file value?
You
> >have to have a way of binding the named argument to the name itself that
is
> >unambiguous.
> To be blunt - just like every other command line program I have ever
> seen... (Specifically, /file xxx is always an argument to /file.)
> Paul
That's because the command line program itself can parse the arguments and knows that /file needs an additional argument. The problem with scripts is that the script host is parsing the arguments and has no way of knowing if /file needs more information or if it's a stand-alone switch followed by an unnamed argument. If you don't want to use colons, your script can walk the WshArguments
object itself; you don't have to use its Named and Unnamed properties.
=-=-=
Steve
-=-=-
|
| Wed, 11 Jun 2003 05:56:18 GMT |
|
| |
|
