So normal output redirection is handled with just the > or >> operators (depending on whether you want to overwrite or append the target file), like so:

dir >> myfile.txt

The operator outputs the stdout stream by default. But it can be modified to output the stderr stream by just specifying that stream with the operator. Remember, stderr is stream 2. So, you would do like so:

dir 2>> myfile.txt

This would write only the error output to the file.

Let's set this up. First, we have a data file named SomeAccounts.txt:

Josh
Mary
Suzy
Amanda
Trisha
Ben

Then, we have ProcessAccounts.bat, which we want to just loop through the accounts in the text file, tell us what they are, and tell us the first letter of the account name (just to have something to do):

Except when you do this, you encounter a problem: All of the values from the FOR loop are the same! It's as if the for loop ran the proper number of times, but it just ran on the last record over and over again! See below:

My account, Ben, starts with B.
My account, Ben, starts with B.
My account, Ben, starts with B.
My account, Ben, starts with B.
My account, Ben, starts with B.
My account, Ben, starts with B.

What's actually happening is the FOR loop is indeed running over every line, and setting the variables as instructed, but the results of those variables being altered isn't echoed until the FOR loop is complete, so the last value of the variable is what displays. This wouldn't be a problem if you were just using your FOR parameter, in this case %%i, but any variables you set while in the FOR loop, like username, experience this "wait until you're out of the loop" phenomenon.

The fix is simple enough, if you know about it! But I've found the solution to be a bit elusive, which is the whole point of sharing it now.

The key is the setlocal EnableDelayedExpansion command. As explained at ss64.com, making this statement before your FOR loop will enable you to display variables as their value at the moment you're referencing them, or their "intermediate values" while in the middle of the FOR loop. In addition to calling the setlocal command, you then have to reference your variables with the exclamation point (!) rather than percent (%) to indicate that you want to use the intermediate value.

Your script will then look like this:

It will now happily act as desired, outputting these results:

My account, Josh, starts with J.
My account, Mary, starts with M.
My account, Suzy, starts with S.
My account, Amanda, starts with A.
My account, Trisha, starts with T.
My account, Ben, starts with B.

Using the Windows binary installer, I had no problem installing Subversion v1.4.5 on the server. I tested everything and Subversion still worked, it showed the new version when accessing via web access, and Trac still worked fine.

Alas: Don't forget that an upgraded version of Subversion will not upgrade your repository. It will upgrade a working copy of a checked-out repository, but it will not upgrade the repository itself.

That said, I was unaware of one more step that you must take to upgrade Subversion on a Subversion/Trac setup: You must also upgrade the Python bindings to Subversion.

This became apparent the next time I created a new repository, which was not a v1.4.x repository, and when I tried to build a Trac environment to point to it, Trac got upset because of the classic "Expected version '3' of repository; found version '5'" error. To fix this, you must set up new bindings to the new version of Subversion, as explained in the TracSubversion page.

Now, I obviously love Subversion and I love Trac, but honestly, straight-forward documentation that is easy to understand for someone who doesn't want to get in the thick of it isn't really the strong suit for these communities, at least when it comes to installation and deployment on the server. What exactly it means--and how to do it--when they say, "Update the Subversion bindings" is not easy to understand. However, the solution is simple. All that is needed is to download the appropriate "svn-python" Windows installer that matches your version of Subversion and Python (in my case, 1.4.5 and py2.3) and run it on the server.

In my case, I had to stop Apache for the installation to succeed. Upon restarting Apache, everything worked great.

It turns out that NTLMv2, the authentication protocol, is required by default on Windows Vista. According to the Samba Features by Release wiki page, support for NTLMv2 in Samba wasn't fully developed until Samba v3.0.21.

Running yum would be a quick way to upgrade Samba to a more recent release. For some reason, though, the repositories I'm pointing to only have v3.0.10 as the latest available update. Rather than hassling with it, I found an article that attacks the issue from the Vista end.

The article Get Vista and Samba to Work explains how to get Vista to use the older authentication protocols, like the original NTLM. After making this change, I was able to login to my shares immediately.

Basically, all you need to do is run the Local Security Policies console snapin (secpol.msc), open Local Policies --> Security Options --> Network Security: LAN Manager authentication level, and change the setting from "NTLMv2 responses only" to one of the more lenient settings, like "LM and NTLM – use NTLMV2 session security if negotiated".

This works for me because I have one, sometimes two, machines with Windows Vista connecting to my server. If you had lots of machines connecting to the server, it'd obviously be worth your time to just upgrade Samba to a version that supports NTLMv2.

WinZip offers a WinZip Command Line Add-on free of charge--if you already own a copy of WinZip Pro!

You shouldn't have to pay for command-line zip. And you don't have to. Enter Info-ZIP. This workgroup has been maintaining free, portable, high-quality versions of zip and unzip. They have plenty of command-line arguments like you would expect from an open source project.

So, with this project's executables in your system path, you can write up a batch file that is executed as a Windows scheduled task. Maybe something like this:

This will zip the c:data directory. Arguments: -q to do it quietly, -S to include system files, -r to recurse into subdirectories. Finally, use -i to point to a file that indicates the exact files to include, by means of a carriage return delimited list.

You can alternatively use -x to specify only which files should be excluded. Perhaps something like this:

The command-line flags are all optional, of course. This tool is certainly a must-have for the Windows scripter.

Nevertheless, in her review entitled Uninspiring Vista, Erika Jonietz explains how Windows Vista, as nifty as it is in many ways, was the straw that broke the camel's back and caused her to appreciate how awesome OS X is and the entire Macintosh experience can be.

A great read for any Mac fan!

Unfortunately, some of us humans might try so hard to leverage our computer's multitasking abilities that the ultimate bottleneck becomes the limit of our own mental concentration. You're working on a document, but you also have your email client open and perhaps a few tabs on your web browser. Before you know it, you've wasted a significant period of time replying to email or going off on a tangent through the web, when the most important task at hand was just to finish typing up that document.

Enter WriteRoom. It may seem archaic by today's standards to boot up your computer into a word processor program and to only be able to use your computer for that purpose until you finish and boot into another program, but it sure didn't test human self-control and concentration like the systems we have today. WriteRoom duplicates that simple, distraction-free experience, and while you're at it, gives you a bit of nostalgic joy in the process. Sure, you could get a similar affect by opening TextEdit (on the Mac) or Notepad (on Windows), but where's the joy in that experience?

Did you grow up on an Apple ][ using AppleWorks with a green-on-black monochrome monitor? WriteRoom's default scheme duplicates just that environment. Did you have the DOS PC's common white-on-blue? Or can you just not stand anything but black-on-white? Fine, the color scheme is customizable. So is the font, so you don't have to stick with a monospaced font, although it sure adds to the nostalgia.

And the best part is that you don't have to give up the multitasking bit to use WriteRoom. You can run iTunes and download that huge file in the background, but experience a visually simple and uncluttered experience while working on your text document.

WriteRoom is for the Mac only, and the original version is free. A clone called Dark Room was written to respectfully "capture the essence of WriteRoom" for Windows machines, and is also free.

The ODBC services would not start, and although the "ColdFusion MX 7 Application Server" service was started, browsing ColdFusion pages received an odd error page:

500 NULL

There was a Macromedia TechNote about this matter, although it was unresolved as of the TechNote's last update.

Whereas a Google search will uncover many other times this error may pop up, my circumstances applied after the OS upgrade and on every single page view in its entirety.

The TechNote gives a good hint when it says the error can be caused by an empty or missing license.properties file. My answer was similar: The user that the ColdFusion service was running as didn't have permission, after the upgrade, to read from the CFusionMX7 directory.

I gave the user read rights and everything began working wonderfully.

Even though I think it is pretty blatant, for those of you who do not realize: David is using a common linguistic tool known as sarcasm.

There are graceful ways around the issue. You can (a) Reset one of the connections remotely, freeing up room for you, or (b) Connect to the computer's console session and then reset the sessions from a GUI interface.

Resetting connections remotely. This method is more graceful, but requires a bit more work. As Scott Forsyth described in Managing Terminal Services Sessions Remotely, the qwinsta (query windows station) and rwinsta (reset windows station) commands can help you accomplish this.

Use qwinsta to find a session to clear, or reset:

C:>qwinsta /server:MyServerName
SESSIONNAME USERNAME ID STATE TYPE DEVICE
0 Disc rdpwd
rdp-tcp 65536 Listen rdpwd
console 5 Conn wdcon
rdp-tcp#59 MyUserName 2 Active rdpwd

In this example, "MyUserName" has a session, and I could clear that session to take it's place. To do that, I would use rwinsta to clear the session, which has an ID of 2:

C:>rwinsta 2 /server:MyServerName /V
Resetting session ID 2
Session ID 2 has been reset

With the session being reset, I could now successfully login with Remote Desktop.

Connecting to a console session. Windows will always have a console session, which is the session that represents the session outputting to the physical monitor, if one were plugged in. If a user were logged into the machine and physically using the mouse, keyboard, and monitor that are plugged into the machine, and you then connected remotely to the console session, their session would be disconnected and you would connect to that console session. Obviously, this is not the typical approach you would want to take, but it is an option when you need to force yourself onto the computer.

Basically, this is accomplished by running Remote Desktop from the command line (mstsc) and invoking the command line argument to connect to the console session.

mstsc -v:MyServerName -console

That's all there is to it! At that point, you can either proceed with your work or use the console session to clear any other Terminal Services sessions in the Terminal Services control panel.

Apple is taking steps to correct the matter, and apparently it is an extremely small percentage (less than 1%) of affected iPods.

In the Information Week article "Apple Says Shipped iPods Carrying Computer Virus", statements from both Apple and Microsoft are quoted. Allow me to translate and paraphrase.

Apple: "We're sorry for shipping our iPod with a Windows virus. Gee, it's too bad Windows is so bad with viruses."

Microsoft: "Yeah, but you're stupid for letting the virus get on your product, even if, erm, it doesn't affect your own OS. Just watch it in the future, will ya?"

That is exciting, and the timing is of course very comforting.

I was naturally livid when I read about Microsoft pulling UEFI support from Windows Vista on March 14. For many users who highly prefer Mac OS X but want the flexibility to use Windows when necessary, the Intel transition was an excitement followed by frustration when we realized that Windows XP was not cognizant of UEFI. For us, Windows Vista seemed the best, cleanest solution. eWeek's David Morgenstern holds that Microsoft's EFI pullback is Apple's gain, which is a positive attitude but I don't feel there is much realistic validity to his opinion; Vista's EFI-lessness gives Mac users one more bullet on their bragging rights list. That helps us dual-boot Windows on our Macs how? And it makes Windows users wish they were running OS X for what major benefits?

Furthermore, Microsoft is not expressing any interest in expediting the development of a Universal, Intel native version of Virtual PC.

Although there have been understandable and reasonable explanations for both of these scenarios that are unrelated to Microsoft's interest in the success of the new Macs, the zeal in us loyalists moves us to irritation and suspicion that Microsoft may be making a passive/aggressive move to frustrate the Intel transition.

Alas, another day, another innovation in this incredibly busy year in the Apple universe. Some hackers have finally been able to answer the challenge on OnMac.net to successfully get Windows XP installed on an Intel Mac! He has posted photos and even a video as proof of accomplishment, in addition to the required patched files and instructions. At this point, it has been tested and verified by numerous sources and testers.

My need to purchase a new PC just vanished.. Sorry, Dell!

Article: Web Site Reports Intel Mac Dual-Boot Breakthrough.

Darwine is an open source project for Macs (via OS X's open source Darwin) that piggy-backs on the WINE open source project for Linux. Basically, it is a project to allow Windows applications to run on your computer without the Windows operating system. It does this by emulating the Windows APIs.

So a Red Hat box could run a Windows application side-by-side its X11 apps. This is obviously a bit easier on an x86 build of Linux; thus the separate project--Darwine--for running Windows apps on Mac OS X on a non-Intel processor. Well, with the advent of Mac OS X going Intel native, this task just got a whole lot easier. Which is a relative statement, of course, because in general the premise of the project is very challenging, and notably also very volatile. For instance, the project is limited in what applications can run, and this is after years of development during the stagnant period of Windows XP inactivity. With the release of Windows Vista, undoubtedly the project will be broken yet again for quite some time.

But my purpose isn't pessimism. My featured article today (MacSlash: Darwine Not Functional On Intel Macs) reports the great progress they've made in getting Darwine to work on Intel Macs, and ponders the possibilities of future progress. It is exciting to see this development; it is very sad that this project will probably never have the time or development energy to mature into something that can be used on a wide scale.

Nevertheless, it is worth keeping an eye on!

First of all, the error message may look something like this: "OpenSCManagerA Error - Error Connecting To Service, Error Number=0". Your mileage may vary slightly.

But the software actually is fully installed. My guess is that SP2 messes with security permissions that prevent the installer from starting or restarting some services. Once the intended processes cannot complete, the installer spits out that nasty message, and upon your clicking "Okay", completely removes the installation.

I don't know how thoroughly this solution works, but if you copy the installation directory that is created in the Program Files directory (for instance, "c:Program FilesiTunes") after the error message appears but before clicking "Okay", it appears that you acquire all the files from the installation. Click "Okay" and the installer uninstalls the files. Then just place your copy of the iTunes directory back into the Program Files directory, and you have a working version of iTunes. You can then make shortcuts in the Start Menu or wherever else you want them.

Too complicated for your taste? Send your curses to Microsoft for breaking existing software and go buy a Mac. For everyone else, I hope this proves helpful.

It is mentioned in: Jobs rebuts eco-group claims at annual meeting.

According to MacWorld, when Jobs was asked about the release of Mac OS X Tiger and the upcoming Longhorn, he said, �They are shamelessly trying to copy us...I think the most telling thing is that Tiger will ship at the end of the month and Longhorn is still two years out. They can�t even copy fast.�

What a great line!

Read about it at: Longhorn in 2006: Can Microsoft Really Pull This Off?

Granted, opinions are just that, nothing concrete. But the opinions are a reflection of Microsoft's track record, which is indeed concrete, and not flattering for Microsoft.

To Microsoft's credit, at least they are readily acknowledging that Longhorn won't be ready any time soon in 2006; when you look at the schedule of events surrounding the Longhorn release, you can see that they anticipate it hitting retail shelves (and bundled with Wintel machines) in time for Christmas 2006. That places the release date 20 full months away, a lot further than the short 8 full months before the beginning of 2006.

Nevertheless, many things have to happen between now and then, starting with a working beta, which Microsoft is already overdue on delivering.

Let's just sit back and see what the giant pulls off.

Please read: Tiger on Track for Mid-April Release

Granted, all Apple ever promised was "in the first half of 2005." Understandably, everyone translated that as "in the summer of 2005," a reasonable conclusion. How pleasantly surprised we all will be if Apple could push out Tiger in early May, potentially even in late April!

Well, if you're Microsoft and you've promised a summer release date, why not just change the definition of "Summer"?

Please read: Microsoft Clarifies SQL Server Ship Date.

I always thought it was commonly understood in the United States that "Summer" indicated anytime in the months of June through August. However, Microsoft has indicated that they are not altering SQL Server's release date--they are merely clarifying what they meant by indicating "Summer 2005"--by rewording it to "the second half of 2005", which I understand as anytime in the months of July through December.

Don't rest on the crutch of petty word games; if you can't release your product by your latest promised release date, accept the truth and report it as such. I'm sure SQL Server will barely make a 2005 release date, if at all.

So now I've wised up. Just today I made a "perfect" Windows install, with SP2, my anti-virus software, my preferred settings, and a couple of my most commonly used programs. Now that that's done, I use a Linux Live CD--which for the uninitiated, is a Linux bootable CD--and now I'm imaging my Windows partition with Linux.

How, you might ask? It's simple!

Once Linux boots up, I first login to my fileserver, which is coincidentally a Linux system as well, but it doesn't have to be. In fact, I'm actually connecting to it using Samba. Then, I simply use the DD command:

dd if=[The partition you want to image] of=[The location of the file to save]

So, in my exact case, I mounted the fileshare at /ramdisk/bkup, and my partition was /dev/hda1, so:

dd if=/dev/hda1 of=/ramdisk/bkup/WinXPSP2.img

Check out the Top 10 Questions About Virtual PC from Microsoft, then scroll down to Question #10, "Does Virtual PC make my Mac more vulnerable to computer viruses?"

Indeed, in the answer, Microsoft openly acknowledges that Mac users are obviously exposed to the same vulnerabilities of a PC while they are running Virtual PC. Obviously--thankfully--these viruses will not be able to operate while any virtual machines running Windows are deactivated, and even if viruses do propagate to a Mac volume (by means of shared folders, for instance), they will not be able to run under the Mac environment. Nevertheless, the door is open for Mac volumes to be littered with virus files if a virtual machine running Windows is infected on Virtual PC. Indeed, this happened to me a few years ago, and it was a pain, because the virtual machine running Windows littered my Mac with virus files.

Microsoft is certainly forced to make such acknowledgments, and it is oh so sweet!