----- Original Message -----
From: "Angus Leeming" <[EMAIL PROTECTED]>
To: <lyx-users@lists.lyx.org>
Sent: Tuesday, December 13, 2005 2:41 PM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]
Think of both the registry and the PATH environment variable as simply
*hints* of where to find a given executable. The LyX installer uses the
registry to generate the \path_prefix string which, in turn, is used by a
lyx.exe process to modify its local copy of the PATH environment variable.
Note that the lyx.exe process hasn't looked for any other .exe binary at
this point.
When it comes to do so, it will look for (say) python.exe only in those
directories that are components of its own copy of the PATH environment
variable.
I installed LyX after deleting all of the LyX helper programs from the
PATH environment variable. That means LyX doesn't need the PATH
variable for locating programs that are installed or need to be installed
because it did so without any information available from/provided by
the PATH. Angus wrote:
"The installer searches the Registry in various ways in order to find the
whereabouts of sh.exe, gswinc.exe, python.exe, etc. It's blindingly
obvious that it should first ascertain whether these things are already in
the PATH. Never mind ;-)"
SH: Whether the LyX installer finds something in the PATH, everything
in the PATH, or nothing in the PATH, it still installs properly. From
these facts it is a bit hard to arrive at the conclusion that "It's
blindingly
obvious that it should first ascertain that these things are already in the
PATH." And even if you later find it convenient to prepend what LyX
discovers to the Windows PATH, where does that involve ascertaining?
Your explanation is good, it seems, but it doesn't follow consistenly
from "It's blindingly obvious that it should first ascertain that these
things
are already in the PATH." Does LyX delete duplicates in the PATH in
order to use the word ascertain? Apparently not.
So, it doesn't really matter if your registry or your "global" PATH (as
visible from, say, cmd.exe as "echo %PATH%") contain ancient cruft so long
as the local PATH environment variable used by the lyx.exe process
contains the directory that actually holds python.exe. That's the beauty
of the \path_prefix for you; you, the user, have total control.
But you also wrote:
"Formally, that's the PATH environment variable. To be honest, I don't think
that I check the contents of this variable when generating the contents of
\path_prefix. Clearly I should have ;-)
Within LyX we prepend the contents of \path_prefix to the global PATH,
creating an augmented PATH for this process and all of its children
(spawned processes)."
SH: If you are not checking the contents of the PATH variable how do
you does it follow from that statement that: "It's blindingly obvious that
it
should first ascertain that these things are already in the PATH."
(5.) I've had programs like flpsed and preview that have substituted
for gsview and they aren't written to the registry or PATH. I did put
them as file format viewers. If I had put either one in the PATH,
the LyX installer would not have know to use them in place of
gsview if I did not have that on the hard drive. This last point (5)
is quite minor, I just added it to explain my AI remark.
You're getting things a little confused again I fear. The PATH tells LyX
*where* to look for something, not *what* to look for.
I said registry or PATH. I meant they wouldn't show up on the radar
because grouping by functionality isn't supported. When it comes to
grouping for duplicate entry purposes, finding out what are the duplicate
names is hard, because the PATH may have duplicate entries. Comparing
to the short (5 or 6) list of helper files that LyX discovers is a procedure
which supports a lot more specification than a list of possible duplicated
PATH entries. Unless LyX just uses it own contributed prepended entries
to the PATH, anyway that is how it seems to me. I am talking about
comparing what the content of the PATH is in terms of characters.
I thought you advocated a configure.bat which would compare what
paths are written, ascertaining which paths are duplicates. Something
that would eliminate an extra 200 characters of repeated directory paths.
That is going to be hard to do without even getting to finding similar
functions, especially since using the Windows PATH may not contain a
single one the directory paths which gets duplicated in configure and
written to \path_prefix. I'm wondering why if LyX can store the 5 or 6
helper program directory paths and prepend them to Windows PATH,
why it can't store this information for a later comparison to the configure
output section of \path_prefix.
This last point is incidental curiousity, maybe there is a good reason
for however you do it. My main point is that your explanation does
not match a claim that the LyX installer must _first_ ascertain that
these things are in the PATH. If there is no checking done then I
don't think the word ascertain applies, and since LyX can install
correctly without itself or any helper programs in the PATH, then
checking/ascertaining seems to apply to later in the process.
When it comes to do so, it will look for (say) python.exe only in those
directories that are components of its own copy of the PATH environment
variable.
But LyX installs properly without any executable referred to by any
part of the Windows PATH environment variable. If LyX has located
any of these executables and prepended them to its own copy of
the PATH variable it hasn't used the Windows PATH for anything but
a place to hang its hat. The Windows PATH doesn't need to contribute
anything to the discovery of the executables and directory paths. Else LyX
would not have installed properly with zero LyX helper apps in the PATH.
Which is a far cry from blindingly obvious that the Windows PATH is
required to ascertain first, that these things are already in Windows PATH.
Regards,
Stephen
