Source Code Placement

I always recommend that you download the source code for my books. The Verifying Your Hand Typed Code post discusses some of the issues that readers encounter when typing code by hand. However, I also understand that many people learn best when they type the code by hand and that’s the point of getting my books—to learn something really interesting (see my principles for creating book source code in the Handling Source Code in Books post). Even if you do need to type the source code in order to learn, having the downloadable source code handy will help you locate errors in your code with greater ease. I won’t usually have time to debug your hand typed code for you.

Depending on your platform, you might encounter a situation the IDE chooses an unfortunate place to put the source code you want to save. For example, on a Windows system it might choose the C:\Program Files folder (or a subdirectory) to the store the file. Microsoft wants to make your computing experience safer, so you don’t actually have rights to this folder for storing your data file. As a result, the IDE will stubbornly refuse the save the files in that folder. Likewise, some IDEs have a problem with folder names that have spaces in them. For example, your C:\Users\<Your Name>\My Documents folder might seem like the perfect place to store your source code files, but the spaces in the path will cause problems for the IDE and it will claim that it can’t find the file, even if it manages to successfully save the file.

My recommendation for fixing these, and other source code placement problems, is to create a folder that you can access and have full rights to work with to store your source code. My books usually make a recommendation for the source code file path, but you can use any path you want. The point is to create a path that’s:

  • Easy to access
  • Allows full rights
  • Lacks spaces in any of the path name elements

As long as you follow these rules, you likely won’t experience problems with your choice of source code location. If you do experience source code placement problems when working with my books, please be sure to let me know at


Avoiding Unwanted Spaces

Some time back, I created the Adding a Location to the Windows Path blog post to help readers make better use of some of my book examples. Adding a location to the path makes it possible for Windows to locate applications with greater ease. However, that post didn’t make it clear that a space in a path would cause problems. For example, a path such as, C:\Windows; C:\Python33 (note the space) won’t work. In order for the path to work, each individual path must be separated from the others with just a semicolon, such as C:\Windows;C:\Python33. If you’ve added a path to your Windows setup and find that Windows can’t locate the applications you want to use, please check for an unwanted space in the path.

The limitation on using spaces in a path makes sense because you also have to restrict their use at the command line. For example, typing Dir /A D (with a space between the A and the D) will produce an error. In order to obtain the correct results, you must type Dir /AD and press Enter. The reason the space causes a problem is because the command processor treats spaces as a delimiter, a separator between command elements. The space tells the command processor that one element has ended and a new one has started.

Spaces can creep into commands with relative ease. All it takes is a relatively simple tap on the spacebar at the wrong time. In addition, spaces can be hard to spot when you use certain fonts. When working in an editor to create batch files or other permanently stored command forms, always use a mono-space font, such as Courier New, to make spaces easier to spot. The point is to look for unwanted spaces when a command line feature doesn’t work properly and you know you have typed the correct command.

As a reminder from my books, the command line can also be case sensitive in some cases. Make sure you check your commands to ensure they’re formatted correctly. Let me know about your book-specific command line issue at


Adding a Location to the Windows Path

A number of my books tell the reader to perform tasks at the command line. What this means is that the reader must have access to applications stored on the hard drive. Windows doesn’t track the location of every application. Instead, it relies on the Path environment variable to provide the potential locations of applications. If the application the reader needs doesn’t appear on the path, Windows won’t be able to find it. Windows will simply display an error message. So, it’s important that any applications you need to access for my books appear on the path if you need to access them from the command line.

You can always see the current path by typing Path at the command line and pressing Enter. What you’ll see is a listing of locations, each of which is separated by a semicolon as shown here (your path will differ from mine).


In this case, Windows will begin looking for an application in the current folder. If it doesn’t find the application there, then it will look in C:\Python33\, then in C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common, and so on down the list. Each potential location is separated from other locations using a semicolon as shown in the figure.

There are a number of ways to add a location to the Windows path. If you only need to add a path temporarily, you can simply extend the path by setting it to the new value, plus the old value. For example, if you want to add C:\MyApp to the path, you’d type Path=C:\MyApp;%Path% and press Enter. Notice that you must add a semicolon after C:\MyApp. Using %Path% appends the existing path after C:\MyApp. Here is how the result looks on screen.


Of course, there are times when you want to make the addition to the path permanent because you plan to access the associated application regularly. In this case, you must perform the task within Windows itself. The following steps tell you how.


  1. Right click Computer and choose Properties from the context menu or select System in the Control Panel. You see the System window shown here open.
  2. Click Advanced System Settings. You see the Advanced tab of the System Properties dialog box shown here.
  3. Click Environment Variables. You see the Environment Variables dialog box shown here. Notice that there are actually two sets of variables. The top set affects only the current user. So, if you plan to use the application, but don’t plan for others to use it, you’d make the Path environment variable change in the top field. The bottom set affects everyone who uses the computer. This is where you’d change the path if you want everyone to be able to use the application.
  4. Locate the existing Path environment variable in the list of variables for either the personal or system environment variables and click Edit. If there is no existing Path environment variable, click New instead. You see a dialog box similar to the one shown here.
  5. When adding a new variable, type Path in the Variable Name field.
  6. Add the path you want to use in the Variable Value field. Click OK three times to close all the dialog boxes.

When you open a new command prompt, you’ll see the new path in play. Changing the environment variable won’t change the path for any existing command prompt windows. Having the right path available when you want to perform the exercises in my books is important. Let me know if you have any questions about them at