Re^4: The Evil Embedded Space

(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.

Comment on Re^4: The Evil Embedded Space

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]