-----Original Message-----
From: billious [mailto:
[email protected]]
Posted At: Sunday, October 01, 2006 7:41 PM
Posted To: microsoft.public.win2000.cmdprompt.admin
Conversation: need help getting yesterday
Subject: Re: need help getting yesterday
Alexander Suhovey said:
-----Original Message-----
From: billious [mailto:
[email protected]]
Posted At: Sunday, October 01, 2006 5:16 PM
Posted To: microsoft.public.win2000.cmdprompt.admin
Conversation: need help getting yesterday
Subject: Re: need help getting yesterday
DATEINFO is 250 lines of code while in VBScript anything you
would
ever
need to do with dates will fit in a single line of code.
--
Alexander Suhovey
Yes, but a VBScript solution is a VB solution in a script format,
and
fits
in better with VB groups like
microsoft.public.programming.scripting.vbscript,microsoft.public.scripti
ng.vbscr
ipt
or microsoft.public.vbscript, not script groups.
Claiming VBS files are script solutions is like describing a batchfile
consisting of a sequence of .wav and .jpg invocations as "scripting a
multimedia composition."
Well, I'm not sure if I can agree with that.
microsoft.public.win2000.cmdprompt.admin is perfect for anything that
covers windows2000 command prompt administration and cscript fits
perfectly here since its CLI part of WSH.
As for Visual Basic Scripting Edition not being scripting language -
It's new for me. I'm not sure I understand your analogy regarding wav
and jpg invocations. Can you please elaborate on your definition of what
is and is not scripting?
For me script is a series of commands that are interpreted by scripting
host at runtime. CMD in addition to being an interactive shell has
scripting language. ftp.exe, netsh and several others also have
scripting capabilities though very limited to the point that one could
argue that it's not a language.
cscript however is scripting host natively supported by Windows with
scripting language whose superiority over cmd's one I think is obvious.
No need for a war about it - it really depends on where you define the
borders of "scripting" - and this group seems to be oriented toward
"cmdprompt" and hence CMD.EXE
People used to post QBASIC programs in alt.msdos.batch, surround them with
a
batchscript shell, and claim that they were therefore batch solutions. Same
thing with assembler. Yet they disregarded the QBASIC and assembler groups.
Now we have VBScript, described by Microsoft as "Visual Basic Scripting
Edition"
(
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/script56/html/0a8270d7-7d8f-4368-b2a7-065acb52fc54.asp)
- and effectively the same discussion.
In creating a VBScript solution, are you programming a script, or are you
programming in VBasic and invoking it via a script? I believe the latter -
and since there are already THREE separate Microsoft VBScript groups, then
why is it necessary to use the "it's scripting" excuse to make this group
yet another VBScript group - that is IN ADDITION to the NON-Microsoft
VBScript groups AND the VB groups?
Actually, this is a CMDPROMPT group - what the "admin" has to do with
anything is beyond me. It's the closest Microsoft... group to a batch group,
hence it's apparently the default for batch.
So if we have a batch
start "" somesound.wav
start "" somemovie.mpg
start "" somepicture.jpg
this is undoubtedly a batchfile, and a script file - but is it a multimedia
file?
By the same token, invoking a .vbs file may or may not be scripting - but is
certainly programming in VB, for which there are already many groups.
And on the same theme, there are perpetual advocates of 4DOS and similar
replacement command-processors who make similar advocations for their
preferred software, regardless of the fact that there are groups dedicated
to discussion of THOSE things too.
bilious,
No war here. I love batch scripts. But in case of date/time math?
Puh-leese...
'cmdprompt' does not seem to me like same as 'batch'. I thought this
group would cover any CLI-based administration in Windows. Builtin
preferably, yes, so 4DOS and the like probably does not belong here. But
I don't see any point in trying to limit yourself or anybody asking
questions here to batch only if there are other better builtin
scriptable comman-line ways to get the job done. Again, in this case vbs
solution integrates nicely in existing batch scripts without any
third-party tools and/or system reconfiguration.
Now, on your question:
In creating a VBScript solution, are you programming a script, or are you
programming in VBasic and invoking it via a script?
It's first obviously. Same as with cmd/bat files: you write a script,
you run it. For batch/cmd you have a cmd.exe interpreter, for vbs/js -
wscript.exe and cscript.exe parts of Windows Scripting Host (WSH). Sure,
since the only CLI shell available in 2k out of the box is cmd.exe,
cscript as a CLI utility just has to be run in cmd but this doesn't make
vbs less of a scripting any bit.
Actually, this is a CMDPROMPT group - what the "admin" has to do with
anything is beyond me
Probably it's because you are just too concentrated on cmd part. I read
this group name as "Windows 2000 command line administration" which in
no way limits it to batch scripts.
So if we have a batch
start "" somesound.wav
start "" somemovie.mpg
start "" somepicture.jpg
this is undoubtedly a batchfile, and a script file - but is it a multimedia
file?
Same as
WScript.Run ("somesound.wav")
WScript.Run ("somemovie.mpg")
WScript.Run ("somepicture.jpg")
Is undoubtedly a [part of] vbs file and a script file, but it is not
multimedia file.
By the same token, invoking a .vbs file may or may not be scripting - but is
certainly programming in VB, for which there are already many groups.
Invoking vbs file is in no way different as invoking bat file. It's
invoking the script with appropriate script handler.
is it necessary to use the "it's scripting" excuse to make this group
yet another VBScript group - that is IN ADDITION to the NON-Microsoft
VBScript groups AND the VB groups?
Not necessary at all. Nobody tries. At least I'm not. What I did is I've
tried to provide the best solution to the problem. If OP decides to take
a deeper look at WSH, (s)he probably will better ask vbs-related
questions in dedicated groups. I personally use cmd scripts A LOT. As
well as WSH. I just use the best tool to get the job done. Preferably
the tool that already there out of the box. In some cases it is batch.
In this particular case it's undoubtedly vbs/js. I don't see any point
in making things harder just for the sake of "pure batch only". Let's
say you stick to the batch scripting no matter what. Do you use ping,
ipconfig, netsh, ftp -s, net <subcommand>, you name it in your batch
scripts? Leave alone whole scripting or not discussion- Why not cscript
/nologo %tvbs% then?..
I just fail to see any point in this.
And on the same theme, there are perpetual advocates of 4DOS and similar
replacement command-processors who make similar advocations for their
preferred software, regardless of the fact that there are groups dedicated
to discussion of THOSE things too.
It's not on the same theme. WSH is not a replacement to command
processor. It's another (more powerful) builtin scripting host that was
there in Windows for aeons. And for the dedicated group, I've already
mentioned my view on what this group is about.
