Jean-Marc Lasgouttes wrote: > Angus> Clearly, the fix is to ensure that the '\' characters are > Angus> converted '/' ones. However, what function am I supposed to > Angus> use? I find these: > > Angus> string os::slashify_path(string p) > > Angus> string os::internal_path(string const &p) > > Angus> So, on _WIN32 the two functions are identical. But what is > Angus> happening under cygwin? Anyone have any clue? > > I think we should probably use only internal_path and only work inside > LyX with paths which use / as separator. Of course, a second problem > is that win32 names will retain drive numbers, but stuff in filetools > should take care of that. > > A grep shows a lot of uses of slashify_path, I wonder what would > happen if we changed these to internal_path. As far as I can see, this > could do harm only on cygwin...
Agree. Shall I prepare a patch? For 13x too? > I would say that all paths that come from the os should go through > internal_path and then external_path should be used for all processes > invocations. I pulled the cygwin sources. Attached is the code for cygwin_conv_posix_path_to_win32 et al. Not exactly lightweight, is it? Two questions arise. 1. Is it acceptable to always use internal_path, therefore, for cygwin or will there be a performance hit? I'd guess that it's Ok, but... 2. Why don't we need to do something similar for Windows? Is it because we plan to store the paths internally as C:/Windows/Bar and so don't have to worry about this mount table nonsense? -- Angus
path.cc.bz2
Description: BZip2 compressed data
