On Sat, 18 Oct 2014 23:19:58 +0200, Hans-Bernhard Bröker
>Am 18.10.2014 um 20:01 schrieb Paul S. Person:
>> Invoking wdw this way /used/ to work. It appears to be ignoring the
>> Patth environment variable. Any ideas what is causing this?
>More likely than not, it's the contents of %PATH% that's doing this to
>you. E.g. Windows used to require blanks in the %PATH% to be escaped /
>avoided, but at some point they stopped doing that. Who knows what wdw
>might to with unescaped blanks in there...
I made a few changes to the official Windows 8.1 global PATH last
night, so I rechecked this and it still behaves the same way.
It is invoked in
and the Path at the point of invocation is: :
am Files (x86)\Windows Live\Shared;C:\Program Files (x86)\AOMEI
Backupper Professional Edition
ram Files (x86)\Perforce
As you can see, the relevant parts have no spaces -- and are listed
Resetting PATH to
(when I reset it, I of course pasted it as a single line, but I have
broken it up a bit for readability above) ... it works! Apparently,
you can't have /any/ spaces in the path, even if the bits actually
being used come first.
So, I guess I will have to modify the path in my setup file to include
only the parts I need, leaving out the stuff in Program Files (x86).
Is this in Bugzilla? Should it be? I mean, DOS/Windows paths are ended
by ";" or EOL, not by spaces, and the only thing wdw has to do is pass
each segment to whatever it uses to find files, and so doesn't need to
parse the content of the segment, so isn't this a problem with wdw?
I remember writing code to convert a Path (wgml uses several) into an
array of char *s (one per segment), and I know I tested it, but I
don't recall if I tested it with segments containing spaces.
"Nature must be explained in
her own terms through
the experience of our senses."