Am 25.10.2014 um 17:31 schrieb Richard Heck <rgh...@lyx.org>: > On 10/25/2014 07:26 AM, Stephan Witt wrote: >> Am 24.10.2014 um 01:10 schrieb Stephan Witt <st.w...@gmx.net>: >> >>> Am 23.10.2014 um 23:07 schrieb Stephan Witt <st.w...@gmx.net>: >>>> Am 23.10.2014 um 19:19 schrieb Richard Heck <rgh...@lyx.org>: >>>>> On 10/23/2014 11:47 AM, Stephan Witt wrote: >>>>>> Am 23.10.2014 um 17:16 schrieb Richard Heck <rgh...@lyx.org>: >>>>>> >>>>>>> On 10/23/2014 04:02 AM, Stephan Witt wrote: >>>>>>>> See here for an excellent analysis: >>>>>>>> http://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite >>>>>>>> >>>>>>>> At the moment there is no good solution at hand, sorry. >>>>>>> ...except to run LyX itself from a terminal, right? >>>>>> Yes, probable. But >>>>>> >>>>>> 1. I wouldn't call this a good solution. >>>>> Sorry, no, I only meant: Solution that has a chance of working right now. >>>>> >>>>>> 2. IMHO, you have to run it from terminal not only once as some posts >>>>>> claims. >>>>> Yes, that is my understanding: You have to run it from a terminal every >>>>> time. >>>>> >>>>>> What I want to try: >>>>>> 1. Test and provide an acceptable (hackish) workaround for the PATH >>>>>> problem. >>>>>> 2. See if it helps to pass our modifications to environment variables >>>>>> with the QProcess::setProcessEnvironment() method. If this works we have >>>>>> a way to solve this issue. If this doesn't work - then there is not much >>>>>> hope >>>>>> until the Qt-Library is ready for Yosemite, IMHO. >>>>> Worth a try. >>>> This works in principle. But for "foreground" child execution only. >>>> The reason is the missing parameter for the process environment of >>>> the QProcess::startDetached() methods. >>>> >>>> IMO, preview loader, converter execution, forward search, edit external >>>> material, >>>> custom export and printing is not working on Yosemite. What a mess… >>> >>> I've made a patch for the startDetached() methods with an optional >>> environment parameter >>> and used it in SystemcallPrivate::startProcess(). But it was not executed >>> by LyX on preview. >>> >>> Uhmmm. I didn't know that LyX has a second fork()/exec() implementation: in >>> ForkedCalls.cpp. >>> This one is used by the preview loader. And runCommand() is another >>> incarnation of the problem. >>> >>> It is enough for today. >> I got it. The missing piece was hidden in lyxpreview_tools.py. >> >> The attached patch basically works for me. I've tested successfully >> - reconfigure >> - rescan of installed TeX-classes >> - viewing the tutorial with math-preview enabled >> >> What I've noticed else: >> - the user guide contains non-previewable TeX-snippets (question/answer >> branch demo) >> - runCommand isn't fixed yet, but e.g. format conversion works nevertheless >> on Yosemite >> >> This patch is less readable than the previous one. I tried to avoid to >> introduce further >> ifdef obfuscation of the code. I've tested my patch on Linux with Qt5. > > So, I don't really claim to understand what you've done in this patch, but if > it works, it works. That said, since this code really is only needed on OSX, > doesn't it make sense to protect it with #ifdef? The other reason to do this > is that Apple may eventually see the light. Any claim they are making that > this is bug is really a security feature is BS if it can be worked around > this easily.
Ok, the point is to copy the environment explicitly on execution of a child program. The trick to change the environment with latexEnvCmdPrefix() makes this difficult. That's why I've avoided it and - honestly - I found this trick a bit "hackish" and non-portable. The code in ForkedCall::generateChild() is now very similar to the code in QProcess::startProcess(). There you'll find the duplication of all the arguments of execve(). This is true for Qt-4.8 and Qt5. That's why I cannot see why there should be a different implementation for OSX and POSIX Unix. The only reason may be the safety of the change. But for 2.2 this is less of a problem, IMHO. For the backport this is another story. There I'd prefer a #ifdef variant, too. >> I'd like to get some feedback for the patch before applying it. > > I've tried it, quickly, on Fedora 20 with Qt 4.8.6. I was able to reconfigure > and to export the User Guide. That's good, thanks. >> The next question is - if it is fixed in master - what we want to do with >> 2.1.x. > > Well, my guess is that we have to do *something*, the question is what. I'd > be more comfortable if the code were #ifdef'd. One option is to release an > emergency 2.1.2.1 for OSX only. Another would be to go ahead and prepare > 2.1.3. A handful of bugs have already been fixed for it. There are probably > more people could commit quickly. Both ways are ok with me. I didn't follow the changes since 2.1.2 carefully. Possibly the emergency release is the better, quicker and safer solution. Should I make a patch against 2.1.2 and you create a branch for it if you like it? Stephan
