There is one other technique which is time-honored in multiple scripting
environments for ensuring that specific scripts run as console scripts. It
also resolves the problem of broken console input pipelines on Win32. It
does require an extra script file, but it's straightforward to do.
Assume you want to ensure that the script MyScript.vbs always runs from a
console, and MyScript.vbs is located in c:\apps\bin. What you do is create a
new file named MyScript.cmd and give it the following single-line content:
@cscript %~dpn0.vbs %*
Then you can just run the command "MyScript" if the folder c:\apps\bin is in
your search path or if c:\apps\bin is your current working directory. You
can also specify the path to the batch script instead, even just using
C:\apps\bin\MyScript. Here's what happens.
The command processor automatically matches .cmd files before other script
extensions since .cmd precedes .vbs, etc. in the %pathext% shell variable.
It then runs MyScript.cmd. The initial @ suppresses console output, and the
%~dpn0 gets expanded to the full path of MyScript.cmd, minus the final
extension. The %* becomes any commandline arguments you passed in. So it
looks like this:
@cscript c:\apps\bin\MyScript.vbs <your arguments>
You can use the same content for every wrapper script; just save a .cmd file
with that content in the same folder as your VBScript, with the same base
name as the VBScript. If you're writing a wsf, you would change the content
to read
@cscript %~dpn0.wsf %*
Post by Big DI use Wscript.Echo in many of my scripts and it works fine when the
environment default is cscript. Is there is a command I can use for
writing messages to the console and not caring if the scripting engine is
wscript or cscript?(stdout) I don't want to worry about putting cscript in
front of all my scripts to specify.