Uwe Stöhr wrote: > Am 09.03.2014 20:47, schrieb Georg Baum: > >> I investigated further, and according to >> http://environmentvariables.org/Path the effective path is combined from >> a user PATH environment variable and a system PATH environment variable >> on windows, where the system value takes precedence. This is definitely a >> problem: If the system path contains a wrong python (cygwin python or >> python 3, does not matter), and LyX prepends the path prefix to teh user >> PATH, then LyX cannot prevent using the python from the system path. > > There is a system-wide PATH variable. So for example Python 3 was > installed as admin, the all users have the Python 3 path in their PATH. > besides the system-wide PATH is a PATH for every user. So the effective > PATH is the system-wide one + the user one while the system-wide one is > the first part and therefore takes precedence.
Exactly, and this is the problem: If python 3 (or any other incompatible python version) is in the system path, LyX can do anything to the user path, it won't prevent the wrong python to be found first if a simple "python" is called. There is some magic in LyX to avoid a wrong python on linux (method python() in src/support/os.cpp), which in theory should be suitable for windows as well, but maybe it has a bug? > But LyX does not take any PATH value into account. For example LyX 2.0.7's > path_prefix is on my machine Sorry, but this is not true. The PATH variable is always taken into account. The path prefix of LyX is just prepended to what was there before, so the effective path for child processes of LyX on windows is "Windows System Path" + "LyX Path Prefix" + "Windows User Path" You see the problem? > While writing that lines I am now 100 % sure that the configuration > problem reported for beta 2 must have other reasons. So let's wait for > beta 3 if we get some bug reports there again and then investigate deeper. I don't think so, especially since it is easy to find out whether my findings are correct or not. >>> However, LyX2.1 as it is at the moment is not really usable: >>> While working on the docs, I get a crash each half an hour and I am not >>> able to give a crash recipe. It crashes either when pressing Ctrl+C or >>> Ctrl+V - but LyX crashes immediately without any debug output. >> >> Did you try what I suggested some time ago when you first mentioned these >> crashes? > > No, I cannot remember. What could/should I do? The following paragraph is from my message from March, 4: This is of course a problem (which I don't see on linux btw). It would be interesting to get a call stack of these crashes (either run the debug version, or compile the release version with debug symbols and attach the debugger to the running process after it crashed). Maybe the call stack would ring a bell in the head of somebody. >> I don't think that supporting XP is still needed. > > Windows is on 90 % of all PCs and on about 30 % of all PCS is Win XP: > http://scr3.golem.de/screenshots/1403/XP-Anteil/thumb620/XP-Anteil.png But this will decline quickly soon. We only need to wait for the next big wave of infected PCs being taken over by a botnet or some such. It was in the news recently that criminals are holding back with exploiting security flaws of XP which are not already public, so that they may use them forever after the official XP supports ends. > So the XP market is still much bigger than the market for MacOS + Linux. > If we like it or not, we should support Win XP as long as possible. > Personally I plan keep my existing win XP (I have the 64bit variant which > is in fact win 2003 server and which is still under full support) until > LyX 2.0.8 and 2.1.0. It is really silly and dangerous to keep an XP PC running, so we should not encourage users to do so. If you personally want to spend the effort I don't mind, but it should be clearly stated that this is completely unsupported. >>> The PATH variable is uniform in newer Windows versions. >> >> Do you mean that it is always spelled in uppercase? This is not the case, >> I have personally seen a Win7 PC where it was spelled "Path". You can >> also find a win7 screenshot showing "Path" at >> http://environmentvariables.org/Getting_and_setting_environment_variables. > > I don't understand your concerns- When I execute a batch file with > setx path xxx > or > setx PATH xxx > or > setx Path xxx > > the result is in all cases that xxx is set as Path. I haven't heard that > this is case sensitive. That is what I mean with uniform - all Windows > versions have one Path variable and the command to change it is the same > for all Windows. Sigh. This does not contradict what I tried to explain. The path variable on windows is _not_ case sensitive when you access it through the documented windows API (cmd.exe which interprets the commands you gave above is part of that API as well). However, somewhere internally the name _is_ stored case sensitive. This can be seen in the windows environment variable dialog: On some machines it lists "Path", and on others it lists "PATH". Therefore, it might be the case that there is some bug somewhere which causes case sensitivity to creep in places where it should not be. As I wrote, this bug could be in some windows API function (quite unlikely), or it could be in LyX code. >>> We should only start some action if such a problem arises with Win Vista >>> or newer. >> >> Now I am confused. I always thought that most of the python problems were >> on newer windows versions? If they only occur on XP then we can ignore >> them indeed:-) > > I mean one particular case cannot be the reason to invest a lot of time. I > got so many strange bug reports the last years and sometimes it is only a > corrupted hardware driver that lead to very strange behaviors. I remember > a case where I was in contact with the user for weeks and the reason for > his problems was a corrupted graphics car driver - that is Windows ;-). > But these driver issues appear only very rarely in Win 7, in Win XP the > appeared much, much more often. Please read again what I wrote. I am _not_ saying that this particular problem should be solved. I am looking at the _general_ problem of incompatible python versions, taking this case as an example because we have good information about it. If you now say that this general problem does not exist, then I understand even less why you pressed so hard for last minute support of python 3. Georg
