Silly batch file tricks, redirecting stdout into an evironment variable and %~dp0
Some things in batch files seem like they should be so simple, but I'm embarrassed to say how long it took to come up with this little trick. Maybe YOU knew it already, but you should have posted it in your blog so I could have googled it and been done in the 10 seconds it SHOULD have taken me to solve it :-)
In case you ever have wanted to take the console output of a command line tool and capture it in an environment variable, this works. There may be better ways. Thanks to Scott Colestock for helping dig this one up.
setlocal
sometool.exe > temp.txt
set /p TOOLOUTPUT= < temp.txt
del temp.txt
..do something with %TOOLOUTPUT%...
endlocal
Of course when Monad comes out none of this monkey business will be necessary. By the way, I just listened to another great Hanselminutes podcast on Monad that has convinced me to give it a whirl http://www.hanselminutes.com/default.aspx?showID=12.
Since I'm on the topic of useful/(or useless?) batch file tricks, another little known one I find myself using alot is the "%~dp0" macro which resolves to the fully expanded path to the directory containing the batch file. This allows batch files to run regardless of the current working directory. So for example Visual Studio post build events run with the current working directory set to bin\Debug or (bin\Release). But you probably have the postbuild.bat file sitting up a couple directories along side the csproj/vbproj project file. So adding a %~dp0 in front of things you do in the batch file give you location independence without having to do hard-coded paths or a lot of ..\..'s all over the place. So the following will always find the "sometool.exe" sitting right next to the batch file no matter where it's run from.
setlocal
"%~dp0sometool.exe" > temp.txt
set /p TOOLOUTPUT= < temp.txt
del temp.txt
..do something with %TOOLOUTPUT%...
endlocal