Path handling broken on Windows native XEmacs
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| dvc |
New
|
Undecided
|
Unassigned | ||
Bug Description
Our treatment of paths breaks on the Windows native "port" of XEmacs because:
A. We assume a path separator of `?/', whereas the win32 native "port" of XEmacs (unlike that of GNU Emacs) uses `?\\'. It can be rebound to `?/', but `start-process' and friends currently (XEmacs 21.5 (beta29) "garbanzo") seem to fail when you do this, because they try to run cmd.exe with /-based paths,which of course fails because it treats '/' as a flag-introducer, by ancient contract.
B. We (seem to) conflate the platform-native shell escaping conventions with those of a POSIXy "sh". In a strange twist, the case(s) I've seen look like they try to pass natively-escaped paths to "sh", rather than the other way 'round. However, it doesn't seem to be quite as simple as it sounds, since when I tried rebinding `system-type' to something other than 'windows-nt around the call to `shell-
It also wouldn't help that the usual temporary directories on Windows tend to have spaces in them. ("C:\Documents and Settings\..."), though currently we have a hardwired default of "/tmp" anyway, so this doesn't actually hurt yet. When I tried to change the code to use the proper directory, however, things broke BAD, and I couldn't visit any files in a bzr working tree -- for example, I couldn't go back into dvc-utils.el to "fix" the problem.
One quick way to see this go wrong is (or will be, after I commit and push my other changes to make dvc work at all in Windows XEmacs) to run `dvc-diff' in a bzr tree, mark some files, and then try and commit.
