This is a list of commands for Windows Server 2003 (most apply to Windows XP as well), and here is the list for Vista and Server 2008.

Enter Windows Live Writer.  Everyone else is blogging about it, so hey, why shouldn't I?  Out of the box, it's very, very nice (and free, to boot!).  It's a truly WYSIWYG editor (not the typical WYSI-more or less-WYG-with a few little problems here and there) and that handles all of my typical blogging needs.  Except the whole code formatting thing.  Aha, you say, how does that help? 

Easy. 

WLW supports plugins, and they're (evidently) easy to develop.  Even though it's still in beta, there are dozens of plugins already.  A few of those plugins enable code formatting.  I've chosen to use Steve Dunn's cleverly named Code Formatter Plugin, which uses Actipro's CodeHighlighter web control.  Most of the code highlighters out there only seem to support the Visual Studio types of code (your C, your VB.Net, etc.).  Try to get scripts highlighted and forget about it.  This one does, though, and even though it's not quite the same style of highlighting I'm used to, it's way better than nothing.

Take the scriptlet I wrote in this post.  Hand-styling that was a huge pain, and all I really did was keep the indenting and ensure it was all in a fixed-width font.  But all that indenting added up to a lot of  's and it was easy to lose track of how many I'd already done.

With this plugin to WLW, though, it's a matter of clicking "Insert Formatted Code" or "Insert Clipboard as Code" and you get this instead:

1 for /f "delims=/ tokens=1-3" %%a in ("%DATE:~4%") do (
2     for /f "delims=:. tokens=1-4" %%m in ("%TIME%") do (
3         set FILENAME=basename-%%c-%%b-%%a-%%m%%n%%o%%p
4     )
5 )

Line numbers and everything.  In the future, I'll skip the line numbers for bits of script I intend for people to copy and paste, but to illustrate points, I'll include them.

Ok, enough rah-rah from me.  I have scripts to write.

(But seriously.  If you blog, this is an awesome tool.)

https://support.microsoft.com/Default.aspx?id=74496

The first discusses how (and more importantly, why) the redirection symbols are parsed by CMD.EXE rather than the program you're calling. 

The second points out some of the caveats of blindly accepting input from environment variables.  While it may be a pain to quote the parameters your script takes, it can make troubleshooting easier and, as his post points out, can prevent your day from being ruined.

    echoargs.cmd
    @echo off
    echo %1
    echo %2
    echo %3
    echo %4
    echo %5
    echo %6
    echo %7
    echo %8
    echo %9

If you feed this A B C D E F G H I, you'll get back those letters, one per line.

But, if you try this with a tenth argument, it won't work like you might have thought:

    echo10args.cmd
    @echo off
    echo %1
    echo %2
    echo %3
    echo %4
    echo %5
    echo %6
    echo %7
    echo %8
    echo %9
    echo %10

You'll see that the last line echoes the first argument again, followed by a 0 (A0).  That is, it gets parsed as "echo %1, then 0".  So, how do you deal with this if you need more than 9 arguments?  My first suggestion would be to see if there's a way you can deal with fewer arguments, though that's often not possible.  If you must, you'll need to loop over each argument and deal with them one by one.  Here's an example listing:

At :Top, we check to see if there are any arguments to deal with.  If not, we go to :NoMoreArgs and bail out.  Then (assuming we didn't bail out), we call :EchoArg with the parameter that's first in the list (in this case, A).  :EchoArg takes the parameter it was passed (A) and echos Arg: A.  Once it's done, we use goto :EOF to indicate that we're done with this subroutine.  Control then passes back up to the line just after our call.

This next step is where all the magic happens.  The shift command takes everything you've passed in and shifts them all to the left by one.  That is, what used to be %3 becomes %2, %2 becomes %1, and %1 falls off.  So now, since there was a tenth parameter, that one becomes %9, which means there's now a way of referring to it.

Once we've shifted everything, we go back to the :Top again.  Now since our original second argument (B) has been shifted to %1, we do the same thing all over again.  That gets echoed, we shift again, and C is the new %1 (and K is the new %9).  We keep doing this until we run out of arguments, and then we bail out.

There are a few important points in here:

• For anything you call, whether it's a "subroutine" like :EchoArg or another script (like call foo.cmd), the arguments passed to it are "local".  That is, if you were to call :EchoArg %8 (that is, H in our case), as far as :EchoArg is concerned, that's %1.  It's its own first argument.
• The built-in variable %* (meaning all arguments passed in) is not at all affected by shift.  In our example, no matter how much you shift, %* will still be A B C D E F G H I J K.  This is sort of unfortunate, in my opinion, since there are times that I've found that I wanted to deal with the first (say) three arguments, then refer to "the rest" in one fell swoop, but the only way to do that is shift your way through them one by one.

While we're on the topic of shift, you can see from shift /? that it can also take a switch that indicates where you want to start shifting.  This takes a bit of wrapping your brain around, but it goes like this:

Given a list of arguments A B C D E F G H I J K, a regular shift would change that to B C D E F G H I J K.

But, we could also use shift /3 (for example) to start the shifting at the third argument.  So our A B C D E F G H I J K becomes A B D E F G H I J K; the third argument (C) gets swallowed.  Note that even though you can address 9 elements at a time %1 through %9, you can't do shift /9 and have the tenth argument become the ninth.  You're limited to shift /8. 

Oh well, you can't have everything...

To understand what's going on, you need to know that there are two streams of output from any given command.  There's STDOUT (or "standard out", or "standard output") and STDERR (or "standard error").  Well-behaved executables will output error messages to STDERR and regular output to STDOUT.  In CMD by default, both STDOUT and STDERR are echoed to the console.  You can redirect this output by using >.  Typically this is done to redirect output to a file.  However, this only redirects STDOUT to the file; STDERR will still display on the screen.

On the command line, when redirecting output, 1 (or nothing) means STDOUT and 2 means STDERR.  That is, foo.exe >foo.txt redirects foo.exe's STDOUT to foo.txt, and its STDERR (if any) will display on the screen.  Running foo.exe 1>foo.txt would do the same thing.  To deal with STDERR, use 2>, as in foo.exe 2>foo.txt. 

So, if you wanted all output from foo.exe, you could run foo.exe >foo.txt 2>foo.txt.  As it happens, since that's a lot of typing, CMD has this little shortcut for tying one stream's redirection to another: foo.exe >foo.txt 2>&1 means "Run foo.exe and redirect its STDOUT to foo.txt, and redirect its STDERR to wherever STDOUT goes."

This is all well and good for redirecting to files, but there are also some built-in "devices" which act like files.  NUL is one such "device", which is used to just discard any output.  So running foo.exe >nul 2>&1 would discard any and all output from foo.exe.  Since devices act like files, you'll notice you can't create files that are the same name as a device.

For those of you who are keeping score at home, other output devices off the top of my head include:

• LPT1, LPT2, etc. (parallel ports, usually used for Line PrinTers)
• COM1, COM2, etc., (serial ports)
• AUX (auxilliary device - COM1 by default)
• CON (console - the default device, i.e., your screen)
• PRN (printer - same as LPT1, though something in the back of my mind tells me there used to be a way to reassign this).

Edit: Reformatted for clarity.

    traffic.cmd - This checks my local traffic conditions (thanks to the excellent folks at the WSDOT)
    @start https://www.wsdot.wa.gov/Traffic/seattle/I405_53rd.htm

    weather.cmd - This tells me the current conditions in my area
    @start https://www.weather.com/outlook/recreation/golf/local/98052

You get the idea...

Edit: Changed inadvertant italics

I'd love to know the reasoning behind this; it's not particularly useful unless you're a Linux guy who can't get out of the habit of using /.  Even then, though, it's exceedingly unlikely that you'd precede everything with call.