On Sun, Nov 01, 2015 at 11:47:42PM -0500, PhilipPirrip wrote: > Hi Enrico, thank you for your response. I hope the others will help us > resolve this too.
Given the overwhelming amount of replies, I doubt anyone is interested in this matter. > 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. The default shell. As is done when setProcessEnvironment is not called. > 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 It is perfectly legal to not have a shebang line and sometimes this is even necessary. The shebang line must contain an absolute path to the shell that has to interpret the script. These paths may vary among platforms, so one can construct a first line that simply reexecutes the script with the wanted shell located anywhere in the PATH variable. This is what the "myprog" example script does: it will execute the script using the first perl interpreter found in PATH. This is not something theoretical and it seems it is the way texlive scripts are executed, as discussed here: http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg169646.html > Does the same 'bug' happen on Windows, or is this only for the shell 'bugs' > on *nix? A similar bug affects Windows, because batch files are not executed by QProcess. > 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. No, it means that QProcess doesn't take into account the way a script can be executed on a given platform. See the link below. > 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? Because QProcess is buggy: http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg169634.html > >>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? No, it will happily execute any file whose extension is listed in PATHEXT: C:\> echo %PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC Here, the extension plays the same role of a shebang line. > Isn't that why you had to go back to > using QProcess when calling a viewer on Windows instead of the script... No. > You didn't want that black window to pop out, right? This can be avoided by other means than using QProcess, which didn't solve any real problem but only introduced new ones. > bat files are not > executables, they can be executed... by an executable, which is in this case > cmd.exe. Reasoning along these lines, it also holds true for *nix scripts. > 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? There are converters that actually need to be run with the same environment as the TeX engine. We cannot say which ones they are, so we should assure that they run with the proper environment set. > >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. And linux has to do exactly the same in order to run a script. > 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. This last observation suggests what is the minimal change to be performed, i.e., let the latex run work as if the document dir was the current directory. This means setting the relevant environment variables such that the document dir is also scanned, without replicating the setting for TEXINPUTS. I'll prepare a patch along these lines for review. -- Enrico
