Re^3: The Evil Embedded Space

I'm no MS advocate either, but I don't really buy the argument that this is not in the OS.

First off, spaces in paths have been available for years. I remember using them on DOS 5 and OS/2 2.1. Unix/Linux has always had the ability to put spaces in the path as well. So Windows isn't doing anything new here. What is new here is the advocacy to use spaces.

I look at this as I would any other design that will inherently cause users (in the case of an OS, this includes not just end-users, but developers on that OS) problems. Funny thing is, they could have avoided this by officially endorsing spaces, but using a directory such as C:\Programs instead of C:\Program Files as the directory for default installations. 99% of the problems with spaces would have gone away. Instead, they consciously chose to break everyone in order to enforce their idea that spaces should be allowed. What this means in practical use is that CMD.EXE is deprecated, as is any other non-GUI method of launching applications.

It's a design decision by MS that causes this pain. It means everyone else, especially those writing batch files, needs to change their code. It breaks backwards compatability, which I believe they did on purpose. And thus I'd say the problem is in the OS.

Unfortunately, it is what it is, and everyone who develops for Windows now (well, for the last 10 years now) must eat the cost of the switch. The market (generally) demands it.

I know that, at work, we were still eating the cost of conversion in 1998. And even today, there is a small overhead of having to constantly make sure we quote everything properly in our batch files. What a headache. Our build tools explicitly say "no spaces in their paths" for building. What we ship to end-users must support spaces, but it's too expensive for us to support the spaces internally. Yet another Microsoft-tax - this time on development.

Update: Some may wonder what a rant (yes, a rant ;->) on MS is doing here. It's not. It's a rant on design issues, and how they permeate to everyone that relies on your code and design. Care needs to always be taken that you break your users only when there is no other way to get them the behaviour desired, and I think that simply changing the default location for new software just a tiny bit would have reduced that break measurably. I have no issues with spaces in filenames per se (as I said, I've been doing this for years prior to Win95's arrival). Just the design of how to implement it.

Comment on Re^3: The Evil Embedded Space

Replies are listed 'Best First'.
Re^4: The Evil Embedded Space by polettix (Vicar) on May 30, 2005 at 15:42 UTC
(The funny thing is that I'm known among my colleagues for being Linux-biased and quite adverse to MS). Sincerely, I'd not consider the fact that the default installation directory has a space a flaw in the OS. Maybe my point of view is biased by the fact that there are lots of flaws in that OS IMHO, and this forces me to consider this a non-flaw. Moreover, I'm not a Win32 developer, but I don't see the difference between Win32 and Unix for this particular issue. In my understanding, you have to escape/quote stuff with spaces in both worlds. I agree, the "Program Files" choice was particularly ill-minded, forcing you to take into account paths with spaces all the time (on the contrary, "/usr" or "/usr/local" are more developer-friendly). OTOH, I generally always take into consideration that there may be spaces in all shell variables I use in Linux, paths included, and I tax myself with extra quoting just to remain on the safe side. I'd do it in a batch file as well, without considering this an MS-related tax. To conclude, in at least one field things work better here in Italy: our default installation directory is "C:\Programmi" :) Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))') Don't fool yourself.	[reply]
Re^5: The Evil Embedded Space by Courage (Parson) on May 31, 2005 at 02:28 UTC
Moreover, I'm not a Win32 developer, but I don't see the difference between Win32 and Unix for this particular issue. In my understanding, you have to escape/quote stuff with spaces in both worlds. Here is where problem arise - in Windows shell (cmd.exe) there is no robust and correct way to escape spaces or other character, which could be quoted. The quoting rules are insane: if you have space within parameter, then that parameter should be enclosed into doublequotes. If it contains doublequotes, those doublequotes should be doubled to be treated as single quotes; and even these rules are twisted: there is escape character '^' which sometimes suddenly disappears from command line, as it treated specially. To make things much worse, all rules are changed by some registry settings, and these registry settings could not be used to make escaping scheme sane; maximum you can get is another level of incompatibility. These and other similar quirks are described in README.WIN32 file from within perl source distribution, quite interesting to read.	[reply]