On Thu, Oct 29, 2015 at 09:36:24PM -0400, PhilipPirrip wrote: > Thanks for responding, Enrico. I appreciate it! > > > >I am sorry, but it still doesn't work. > >As you can see, now it doesn't work because setProcessEnvironment() is used. > > I don't understand what that script (myprog) is exactly supposed to do, but > I believe the problem is in it rather than setProcessEnvironment(). > As I said, the patch (be it good or bad), did work for me on Linux, > BIBINPUTS env. variable did have effect as my .bib files were found only > when that variable was defined. > I propose another simple test, it will show you that env variables do get > set by setProcessEnvironment(). Attaching the modified files. > > Hope you'll trust me now ;)
There is nothing to trust but something to understand. A script without a shebang line is executed by the current shell and QProcess doesn't take that into account. Your example works because you add a shebang to your script. This has a real impact and can cause hard to understand bugs. Please, try reading the thread here: http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg169545.html to see that this causes real problems. > >However, even when https://bugreports.qt.io/browse/QTBUG-19885 is solved > >(if ever), we would still be stuck with the current way of setting the > >environment because QProcess does not execute batch files on Windows and > >doing as you suggest would introduce a regression. > > It maybe does not execute cmd_ if cmd_="some.bat", but will execute > cmd_="cmd.exe /c some.bat". The shell will (hopefully) have the environment > variables set by setProcessEnvironment(). > (bat files are not executables by themselves, are they? windows, when you > click on them, starts them by opening cmd.exe first) > This just means that some.bat is not a good cmd, and should be changed to > "cmd.exe /c some.bat" > (now... who and where uses .bat's?) Now I hope you are joking. What would you think if you had to call a converter of yours as "bash myscript" instead of simply "myscript"? Do you expect to have to do that? Batch files are executable and you don't have to type "cmd /c some.bat" to execute them but simply "some". The "cmd /c" prefix is necessary to overcome the silly limitations imposed by QProcess. > >>In a more conservative approach, BIBINPUTS support could be added by the > >>patch I proposed on http://www.lyx.org/trac/ticket/2645 > > > >This can be done, if now the limit for a command line on Windows is 8191 > >characters as documented at https://support.microsoft.com/en-us/kb/830473 > >but you are forgetting BSTINPUTS and TEXFONTS. > > Did anyone complain about the lack of these two? I don't think many people > would need them. The reason I need them are all these ugly hacks with > \input@path here http://wiki.lyx.org/BibTeX/Biblatex The fact that these two are not useful for you doesn't mean that they are not useful. And even if people doesn't ask for them means nothing. It may simply be that they are not aware of them. As an example, see http://www.lyx.org/trac/ticket/6634 where TEXFONTS was not explicitly requested but would have solved that problem. > >Unfortunately, there was > >no discussion about the way it should be implemented. I mean, while > >always setting TEXINPUTS seems reasonable, I don't think it is the same > >for all other variables, and I am actually not really sure that carrying > >the settings of TEXINPUTS is a good idea. Maybe we can use the following > >scheme: > > TEXINPUTS is now by default set to ".:/home/user/current_folder/" > (. stands for the temporary LyX folder, I believe) > BIBINPUTS is now set to nothing; it would be nice to have it set, at least, > to the same two paths as TEXINPUTS > .bib files will still be searched in 'standard bib database directories' > (that in 2015, I bet, no one is using) > > Both of these are for the people (majority, I dare to say) that keep their > lyx and tex and bib and png and ... files in the same folder (for the sake > of portability and easier backups) > > > I therefore do not see the need for this: > > >- set BIBINPUTS if the directory <docdir>/bib exists > >- set BSTINPUTS if the directory <docdir>/bst exists > >- set TEXFONTS if the directory <docdir>/fonts exists > >so that one can put the relevant files in an appropriate subdir in the > >document dir. Ok, this is your opinion, but I have not heard any other one. I will not introduce any change if there is no explicit consent. Points to be discussed are: - Should those variables simply replicate the setting for TEXINPUTS? · Consider that TEXINPUTS is customizable, so it may be unexpected that the other variables are set to the same paths and this could cause problems. Think for example if someone customizes TEXINPUTS for a recursive search in a directory and suddenly some unrelated files are now used instead of the system ones. - Should they be customizable, instead? - If they are not to be customizable, should we allow for them to be set such as to allow for a recursive search? · If the answer is yes, then we could simply set them if <docdir>/texmf exists, under the hypothesis that a texmf tree is replicated there. - Something different from the previous cases? I am all ears. > >>Anyhow, please consider having BIBINPUTS defined in LyX 2.2. PLEASE > > >;) > >I have not so much time ATM, but I will see what I can do. > > > That's why I'm helping you ;) PLEASE > > (wasn't the whole LyX built by the people who didn't have much time AthatM) Maybe. But: More haste, less speed... -- Enrico
