Spaces in Paths

A number of readers have recently written me about an error they see when attempting to compile or execute an application or script in books such as, C++ All-In-One for Dummies, 3rd EditionBeginning Programming with Python For Dummies, Python for Data Science for Dummies, and Machine Learning for Dummies. Development environments often handle spaces differently because they’re designed to perform tasks such as compiling applications and running scripts. I had touched on this issue once before in the Source Code Placement post. When you see an error message that tells you that a file or path isn’t found, you need to start looking at the path and determine whether it contains any spaces. The best option is to create a directory to hold your source code and to place that directory off the root directory of your drive if at all possible. Keeping the path small and simple is your best way to avoid potential problems compiling code or running scripts.

The problem for many readers is that the error message is buried inside a whole bunch of nonsensical looking text. The output from your compiler or interpreter can contain all sorts of useful debugging information, such as a complete listing of calls that the compiler, interpreter, or application made. However, unless you know how to read this information, which is often arcane at best, it looks like gobbledygook. Simply keep scanning through the output until you see something that humans can read and understand. More often than not, you see an error message that helps you understand what went wrong, such as not being able to find a file or path. Please let me know if you ever have problems making the code examples in my books work, but also be sure to save yourself some time and effort by reading those error messages. Let me know if you have any thoughts or concerns about spaces in directory paths at


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


Backslash (\) Versus Forward Slash (/)

A number of readers have noted recently that I’ve been using the forward slash (/) more and more often in my books to denote hard drive paths. Of course, when working on Windows systems (and DOS before that) it’s common practice to use the backslash (\) for paths. However, using a forward slash has certain benefits, not the least of which is portability. It turns out that the forward slash works well on other platforms and that it also works on Windows systems without problem (at least in most cases). Using a forward slash whenever possible means that your path will work equally well on Windows, Mac, Linux, and other platforms without modification.

In addition, when working with languages such as C++, JavaScript, Java, and even C#, you must exercise care when using the backslash because the languages use it as an escape character (a character pair that denotes something special). For example, using \n defines a newline character and \r is a carriage return. In order to create a backslash, you must actually use two of them \\. The potential for error is relatively high in this case. Forward slashes appear singly, so you can copy them directly, rather than manipulating the path in various ways.

There are situations where you must use a backslash in the Windows (and also the DOS) environment. You can type CD / or CD \ and get to the root directory of a Windows system. However if you try to type Dir /, you’ll get an error. In order to obtain a directory listing of the root directory, you must type Dir \ instead. In fact, many native utilities require that you use the backslash for input. On the other hand, many Windows APIs accept the forward slash without problem. When in doubt, try both slashes to see which works without problem. If you see a forward slash used in one of my books, the forward slash will definitely work in that instance. In general, I only use the forward slash when compatibility with other platforms is a consideration. Windows-specific platform information will still use the backslash.

As things stand today, the more you can do to make your applications run on multiple platforms, the better off you’ll be. Users don’t just rely on Windows any longer—they rely on a range of platforms that you might be called upon to support. Having something like an incorrectly formatted path in your code is easy to overlook, but devastating in its effects on the usability of your application.

Let me know your concerns about the use of backslashes and forward slashes in my books at The book that uses the largest number of forward slashes for paths right now is C++ All-In-One Desk Reference For Dummies. I want to be sure everyone is comfortable with my use of these special symbols and understands why I’ve used one or the other in a particular circumstance.