Running JScript in a CMD File

joshpoley — Tue, 15 Jan 2008 19:32:00 GMT

I do a lot of work from a command shell and this is a little hack that I threw together to avoid having to type out "cscript" every time I wanted to run some specific JScript (aka JavaScript) file. Using some arcane aspects of the two languages, it is possible to embed the JScript code in a .cmd file which the command shell can initially execute and then pass off to cscript.exe for the heavy lifting. Below is a sample file, if it all makes sense you can stop reading now, otherwise continue on to see what is happening.

test.cmd

1 @set @cmdinterop=1 /*

2 @echo off

3 set @cmdinterop=

4 cscript //E:JSCRIPT "%~dpnx0" %*

5 goto :eof

6 */

8 var today = new Date();

10 WScript.Echo(today);

The main thing to remember is that the whole file is parsed by both cmd.exe and then cscript.exe. With that key piece of information let's step through the file.

CMD.EXE

1 @set @cmdinterop=1 /*

CMD sees the @ symbols which means "no echo", and then creates a new environment variable named "@cmdinterop" and sets its value to "1 /*". "@cmdinterop" is just a random name we've picked which has no special meaning in and of itself, though the 'at' symbol is important; more information on this will come later.

2 @echo off

Turn off future echoing of commands.

3 set @cmdinterop=

Nuke the environment variable we just set. Someone looking at this might be thinking: not the most efficient CMD script. If we don't need or use the environment variable, why do we create it? The reason is because the first line needs to be a benign statement in both languages: CMD and JScript. It just so happens that "@set" has meaning in both languages and so we make use of that fact to do our dirty work. This line will just clean up what we had to do on line 1, with regard to CMD's processing.

4 cscript //E:JSCRIPT "%~dpnx0" %*

We now have the CMD script invoke cscript.exe and pass in the name of the current file. The "%~…0" syntax is the cryptic way to get at the file-system properties for the current executing script: "d" for drive letter, "p" for path, "n" for the filename, and "x" for the file's extension. We also attempt to pass in any additional parameters by using the "%*" syntax.

At this point, CMD sits and waits for cscript.exe to finish executing, but we will just continue on since we are almost done with CMD's processing:

5 goto :eof

CMD now jumps to the end of the file, thus bypassing all of our JScript code (lines 6+).

CSCRIPT.EXE

1 @set @cmdinterop=1 /*

In JScript, "@set @" creates a variable which can be used for conditional compilation. We don’t really care about the variable which gets created as we will never use it, but what we do care about is being able inject the start of the block comment, which will allow us to ignore all the CMD code (lines 2 through 5):

2 @echo off

3 set @cmdinterop=

4 cscript //E:JSCRIPT "%~dpnx0" %*

5 goto :eof

6 */

Once we skip past all the CMD code we are free to use whatever JScript code we want:

8 var today = new Date();

10 WScript.Echo(today);

@set

From the JScript parser, things are easy as long as you can get the start of a comment block going. The tricky part is getting that "/*" to parse in CMD without causing an error. Luckily for us, "@set" is the magic code which gives us the avenue to do just that because it can be parsed by both languages.

Going forward, you may want to be nice to future readers of your code and sprinkle in a few extra comments:

@set @cmdinterop=1 /* this line interpreted by both CMD and JSCRIPT

@REM Start of the CMD code

@echo off

set @cmdinterop=

cscript //E:JSCRIPT "%~dpnx0" %*

goto :eof

REM end of the CMD code

// Start of the JScript Code:

Standard Disclaimer: As mentioned earlier, this is a hack. I've tested and used this on XP SP2, but changes to the languages and parsers may cause this script to break.

WinDbg’s Hidden Tools

joshpoley — Wed, 02 Jan 2008 22:13:00 GMT

If you install WinDbg (http://www.microsoft.com/whdc/devtools/debugging/default.mspx), you also get a handful of additional command line tools which aren’t necessarily very visible. Some of them are just console versions of the kernel debugger (such as i386kd.exe) and others are for helping you manage a symbol server, but there are a few useful utilities in there that are worth some advertisement to the uninitiated.

tlist.exe

This tool will display all the processes which are currently running and can also give you some useful information about them. For example, the “-c” switch will display the arguments passed into an application and will also often show the full path to the location of the executable. And if you ever need to know exactly which DLLs a program is actually using (as your system will often have multiple copies floating around), tlist can tell you that as well.

kill.exe

One of the other frequently used tools is kill.exe. No more Mr. Nice Guy, this little app will abruptly terminate any application. For the times that a hung program just won’t go away, no matter how much prodding you give it from the UI, “kill.exe -f” is often the quickest solution.

agestore.exe

This little utility lets you easily delete files based off of the last time a file was accessed. This is great for cleaning out old test reports, build logs, or even symbol files (which is why this tool comes with WinDbg).

dumpchk.exe

This application will take a crash dump file and spew out a plethora of information about the crash. This is handy when you want to see some information about a crash dump without having to go all the way into a debugger. This is also a great tool for creating standardized crash logs which you can attach to bug reports.

Software Sleuthing : Command Line

Running JScript in a CMD File

CMD.EXE

CSCRIPT.EXE

@set

WinDbg’s Hidden Tools

tlist.exe

kill.exe

agestore.exe

dumpchk.exe