Hi Enrico, thank you for your response. I hope the others will help us
resolve this too.
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.
I'd rather call this a bug in the script than in setProcessEnvironment
and QProcess. Why would they need to guess what shell they have to
execute. Isn't it polite, at least, for each shell script to have a
shebang line?
http://unix.stackexchange.com/questions/87560/does-the-shebang-determine-the-shell-which-runs-the-script
Does the same 'bug' happen on Windows, or is this only for the shell
'bugs' on *nix?
Something tells me we're never gonna agree, so I'll rest my case.
Nothing has to be changed in SystemcallPrivate::startProcess part of the
code for the BIBINPUTS to work. It would be nice, I think, for many
other reasons, but that's totally up to you.
Fail: "Exec format error" in your test example only points to the fact
that QProcess does not know it's supposed to spawn a shell and execute
the script in it, nothing more.
If instead of myprog script you had a real binary executable (like
proc->start("/usr/bin/ls") or proc->start("/usr/bin/env")) no "Exec
format error" would appear in either case. Why?
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?
Well, isn't that what Windows does? Isn't that why you had to go back to
using QProcess when calling a viewer on Windows instead of the script...
You didn't want that black window to pop out, right? bat files are not
executables, they can be executed... by an executable, which is in this
case cmd.exe. I'm not pretending I know everything about this, I'm
telling all this from my limited experience.
How many faulty converters are there in LyX? Why do they have to be run
the same way LaTeX&friends are, by using latexEnvCmdPrefix? Does evince
(pdf viewer) really need TEXINPUTS variable that gets set by using
latexEnvCmdPrefix?
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.
You type some, but Windows has to spawn a shell, cmd.com, to execute it.
some.bat has no binary code in it, and it is not executable in that sense.
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.
I know, but by the same argument nothing's worth fixing before we can
fix EVERYTHING. biblatex support won't be possible until it's total, no
one wants partial solutions - hope it's not that what you're saying.
Anway... some of the developers here assumed TEXINPUTS covers even bib
files. (see the posts on \input@path) I wouldn't mind if BIBINPUTS were
not even configurable, make them . and the current document directory.
I don't see why this is such a big deal. It's even standard latex
behavior, it always searches in the current dir. The trouble with LyX is
that it compiles in a temp dir, but does not copy any files it does not
know of.
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.
I suggest you just make them know that. Don't call the setting TEXINPUTS
but just INPUTS.
- 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.
How many users really rely on their local texmf tree? I've been using
Linux and LaTeX for 18 years, LyX for at least 14 and I still have no
idea where my texmf tree is or what should generate it.
- Something different from the previous cases?
Maybe. But: More haste, less speed...
I hope you all (developers) understand we're grateful users who are
paying it forward by helping you (or trying ourselves to) make LyX better.
I personally don't need any of these enhancements. I've been working on
another popular project that just switched to using biblatex. It will be
disappointing if it would take LyX another 9 years
(http://www.lyx.org/trac/ticket/2645) to support it, even by just
defining BININPUTS properly.
