Eli Bendersky's website - Microsoft

On spaces in the paths of programs and files on Windows

2011-01-28T16:25:47-08:00

Today while debugging the build of Python 3.2 with Visual Studio, I ran into a caveat with invoking programs on Windows from directories with spaces in their name. The caveat applies equally to the standard C system call, to Windows batch files and cmd /c, and to any scripting/programming language with an interface to system, such as Python.

Suppose I have a program sitting in a directory with spaces in its name. For the sake of example let's take a trivial batch script called dumpfile.bat:

type %1

All it does is print the contents of the file passed to it as the first argument. I will place it in D:\temp\Spaces dir. How do I invoke this script with system? By quoting around the executable name:

import os

cmdline = r'"D:\temp\Spaces dir\dumpfile.bat" paths_with_spaces.py'
print ">> ", cmdline
os.system(cmdline)

This script is named paths_with_spaces.py, so it asks dumpfile.bat to print itself. And this works as expected.

Now, suppose I want to invoke dumpfile.bat on some other file, which also has spaces in its full path. For demonstration I will place a simple text file named file.txt also in D:\temp\Spaces dir.

Then, I write:

import os

cmdline = r'"D:\temp\Spaces dir\dumpfile.bat" "D:\temp\Spaces dir\file.txt"'
print ">> ", cmdline
os.system(cmdline)

Note that I placed the argument filename in quotes as well, since it also contains spaces.

Unfortunately, I get an error:

D:\temp\Spaces' is not recognized as an internal or external command,
operable program or batch file.

Using procmon, I can find out that the os.system call actually invokes:

C:\WINDOWS\system32\cmd.exe /c "D:\temp\Spaces dir\dumpfile.bat" "D:\temp\Spaces dir\file.txt"
>

under the hood. Running this manually from the command-line, I get the same error. So this is a problem with the Windows cmd.exe processor, not my os.system call.

Alas, cmd.exe is indeed exceptionally dumb. Here's a snippet from its documentation:

If /C or /K is specified, then the remainder of the command line after the switch is processed as a command line, where the following logic is used to process quote (") characters:

If all of the following conditions are met, then quote characters on the command line are preserved:

no /S switch

exactly two quote characters

no special characters between the two quote characters, where special is one of: &<>()@^|

there are one or more whitespace characters between the the two quote characters

the string between the two quote characters is the name of an executable file.

Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the last quote character on the command line, preserving any text after the last quote character.

I emphasized the condition which my example fails to fulfill. The solution, it turns out, is to induce the behavior described in (2), by wrapping the whole command-line invocation in another pair of quotes:

import os

cmdline = r'""D:\temp\Spaces dir\dumpfile.bat" "D:\temp\Spaces dir\file.txt""'
print ">> ", cmdline
os.system(cmdline)

This works. Yet another little trick of Windows's wonderful command line.

Resources:

Super User question and answer
Python issue 11034

Running several OSes in one - using VirtualBox

2010-03-27T15:38:31-07:00

Being able to run a fully hosted OS in a window is very useful. With today's multi-core CPUs and loads of RAM, it is actually possible to run a guest OS with very reasonable performance. I should mention that my current PC is dual-core, has 2GB of RAM and runs Windows XP Home edition.

Lately I'm using Sun's (Oracle's these days) VirtualBox software to accomplish that. VirtualBox works very well and is open-source. It keeps surprising me with its simplicity - all the complex things (like sharing files between the host and the guest OSes, and setting up the network on the guest OS) work easily. The most help I ever needed was quickly found in VirtualBox's own help file, without even digging in online forums and Google. That doesn't happen often!

Being completely free and open-source, VirtualBox is much friendlier than the free version of VMWare that only allows you to run "appliances" prepared in advance by other users using the full versions of VMWare. For VirtualBox I was able to trivially install an OS either from and .iso file or from an installation CD.

One of its best features is the "seamless mouse integration". This basically means that the guest OS just runs inside a window, and whenever the mouse is in that window, focus is in the guest OS. To return to the host OS, just move the mouse outside the window and click somewhere. No pesky key-combinations required.

So what am I using it for? I'm running two operating systems as guests (not all the time, of course, only when I need them).

Ubuntu 9.04

A great and friendly Linux distribution. I'm using it for all my Linux-related development which is mostly trying various tools that are too difficult to compile on Windows (I have a strong dislike for Cygwin), or testing programs I develop on Windows for portability.

I've installed Ubuntu on VirtualBox from an .iso file downloaded from the Ubuntu repository.

Windows XP

That's right, another instance of Windows XP, installed from the same Microsoft CD as the host (I suppose this is legal), running inside VirtualBox.

Why is this useful? Sometimes programs developed on Windows machines have extra dependencies (mostly DLLs) that aren't apparent on the development machine. For example, some DLL may be required by the program and is by chance present on the development box, but the user doesn't have it!

A virtual Windows XP OS is the perfect solution for testing these problems. It's a completely "virgin" installation of Windows XP, with only the network set up. When I'm creating a new version of a program and want to test its deployment, I copy it to the virtual OS. If it works there - it will work at the user's computer as well! This is very useful for executables created by Pyinstaller, that keep wanting different versions of the MSVC runtime DLLs present.

What's best about this approach is that taking "snapshots" with VirtualBox is super-simple. Say that as part of my installation process I've installed some DLLs on the guest OS, and it's no longer "a virgin". No problem - it takes me only a minute to flip back to a snapshot taken before the installation, and I have a pristine Windows box to test against, once again.

A useful Excel VBA macro

2008-08-28T19:06:43-07:00

Today I've written my first useful macro in Excel VBA. I've had past experience with Visual Basic (a long, long time ago), and it's a simple language, so the code wasn't difficult to craft. What was much more difficult is understanding the required methods and properties of Excel's VBA objects.

The macro dresses as a function (which you can fill in a cell with =func_name(params)). It receives a range, and computes a "special" sum of the elements in it. The sum is special because sometimes the elements are added as they are, and sometimes they're doubled, depending on the text in the adjacent column.

This is far from rocket science, but I'm satisfied because in this case Excel is definitely the right tool for the job, and having the ability to code simple macros greatly enhances its usability.

"Unassigned variable" error in C#

2007-05-20T18:16:19-07:00

Today I was reading about the "unassigned variable" detection of the C# compiler. If you write this code:


int x;
Console.WriteLine(x);

The compiler generates an error: error CS0165: Use of unassigned local variable 'x'. Naturally, I wanted to see how this feature fails, and not surprisingly:


int x;
int y = 1;

if (y == 1)
    x = 9;

Console.WriteLine(x);

Generates the same error. This was expected, of course - since the compiler will have to actually run the program to test for the "unassigned" condition in the general case (which is what happens, kind of, in dynamic interpreted languages like Ruby - where runtime and compile time refer to the same process).

Still, this error in C# is useful, since it can probably detect 99% of the real-world cases.

.NET looks nice

2004-03-28T23:36:00-08:00

When you look at a programming language/methodology/framework and it seems "warm, nice and fuzzy" it's usually a good sign.

I've been digging a little in .NET 2003 Studio in the past couple of days, and it looks like a truly great environment. The design of their CLR is clean and consistent over several programming languages. Many old things were rewritten and allow easier coding. It really looks like a great and very rapid tool for Windows development. In VB 6 it was also possible to throw a reasonable applications with a GUI very quickly, but in VB.NET (and C#.NET) it looks cleaner, better thought out and generally more consistent.

One big disatvantage is distribution. If the person next to me has no .NET runtime installed on his PC, I must copy a 20 MB pack to him in order to make any application work, and this sucks...