Am Freitag, 31. März 2006 15:21 schrieb Enrico Forestieri: > On Fri, Mar 31, 2006 at 01:59:09PM +0200, Georg Baum wrote: > > Enrico Forestieri wrote: > > > > However, you could also use other native apps apart from miktex, so it > > > is useful that both 1) and 2) return either posix- or win-style paths. > > > This is to be independent from the cygwin_path_fix switch and in my > > > patch it is done through the "Use Cygwin-style paths" checkbox. > > > > Not agreed. os::internal_path should always create posix-style paths. Why > > would we want other paths internally? If you think about presentation of > > paths to the user, then I would rather invent a new function > > display_path(), otherwise we mixup things. > > One could argue what os::external_path should do. In fact I am not really > > sure how to handle this on cygwin. > > I do not understand why os::internal_path can return paths like C:/xxx > in the win32 version and cannot for the cygwin version. Note that the > test for an absolute path already takes that into account.
It could as well return paths like C:/xxx under cygwin. I am actually not sure what is better. My point is that it should always do the same for a given OS environment. If we make this configurable we only create confusion and gain nothing. > As regards os::external_path, it should be equivalent to os::internal_path, > as it is on *nix. Do you mean with "equivalent" that it should perform the opposite conversion? > > > As a cygwin app can deal with both posix or win-style paths, we could > > > simply ditch the "Use Cygwin-style paths" checkbox and make 1) and 2) > > > always return pseudo win-style paths (I mean with forward slashes > > > because it seems that most windows programs understand that, even > > > notepad and word have no problems with forward slahes). But chances are > > > high that if you have cygwin, you also use all-cygwin apps, and if one > > > of them tries to be smart about deciding that a path is absolute or not, > > > you are in trouble, because you suddenly find that the current dir path > > > is prepended to your already absolute path. > > > > > > For this reason I think that the checkbox should stay. > > > > The checkbox does not really solve the fundamental problem: On cygwin, we > > don't know which of the external programs needs a cygwin style path, and > > which one needs a native windows path. rather than the checkbox I would > > like to have a more general mechanism, for example a wrapper script that is > > invoked instead of an external program and that can translate the paths. > > The configure script could then write the corresponding entries in > > lyxrc.default. > > This way you simply add complexity. The problem with the checkbox is that normal users will probably not understand what it is for. The advantage fo the more general mechanism would be that all the complexity can be in the configure script, and users are only faced with it when defining a new converter. > As it is now, os::external_path > already returns C:/xxx style paths depending on the checkbox status. > I want simply make that independent of \cygwin_path_fix_needed. I think we all agree that this is right. > Notice that it works. I use it daily without problems with a mix > of cygwin and native apps. I use MikTeX and the native ImageMagick, > all other programs are cygwin's. Never noticed a problem. So you are saying that there is no need to output cygwin style paths to external programs? That would be great. I understand that cygwin programs can also use native windows paths with backslashes. Is that true? In this case I would like the following simple solution for cygwin: - Use native windows paths with backslashes in external_path() - Depending on \cygwin_path_fix_needed, use either native windows paths with forward slashes or posix paths in latex_path() This does not need an additional checkbox, and is simple enough for anybody to understand. > Only recently the [EMAIL PROTECTED] bug has arised, and there is another one > that still has gone unnoticed and that I spotted browsing the sources. > Small things, easily fixed. And at least the [EMAIL PROTECTED] thing has nothing to do with external_path, but with latex_path and mixed up internal paths. Georg
