----- Original Message -----
From: "Enrico Forestieri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <lyx-users@lists.lyx.org>
Sent: Wednesday, December 14, 2005 3:57 AM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]
On Tue, 13 Dec 2005 23:54:21 -0800, Stephen Harris wrote:
No, he did not. I'll get back to that. I appreciate your calm response.
This is what Angus initially said to me:
"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: I did not say that the LyX installer could not search the PATH.
I said that this didn't contribute any information that couldn't be
acquired by other means. Since the PATH can contain duplicated
and non-existent entities it can't confirm reports from other means.
I don't think that that is the meaning of what he said. For example,
if the PATH were searched the installer would have discovered that I
already have an sh.exe from cygwin, as this information is not found
in the registry.
I don't want to generalize from your particular aptitude. I think maybe
(conservatively) 3 in 100 Windows users realizes the value of adding the
LyX helper apps to the Windows Path variable. Which is why I wrote:
--------------------------------------------------------------------------
http://wiki.lyx.org/pmwiki.php/Windows/Temp (about a month old)
"A text by Stephen Harris with the purpose of helping users of Microsoft
Windows choosing to install LyX with an alternative LaTeX distribution
rather than the recommended Miktex, before the use of the LyX installer.
The advice centers on including other Latex distributions into the
Windows Path statement. ...
It is good practice for LyX and its associated programs to be included
in the Windows Path statement, whichever Latex distro you are using."
------------------------------------------------------------------------------------
That is only a draft version, the final is less verbose. I knew about
adding LyX helpers to Windows PATH. I wrote this because I
knew few Windows knew the value, and I don't think any of the
helper apps automatically write themselves to the PATH. So it
has to be done manually. My Windows PATH always matched by
\path_prefix which I appended to the beginning of the PATH, but
of course not all of the Windows PATH appears in \path_prefix.
I did learn from you that I could remove the contents of \path_prefix
since I already had those contents in the start of my PATH. I never
thought about deleting \path_prefix, there was no need to. Since I've
wandered a bit from your comment above, I'm going to repeat it.
I don't think that that is the meaning of what he said. For example,
if the PATH were searched the installer would have discovered that I
already have an sh.exe from cygwin, as this information is not found
in the registry.
I don't think this is a good example, I'll say why first and then provide
one.
I mentioned that I had a test computer. It has Cygwin installed. I deleted
all reference to LyX and helper apps from the PATH. I put C:\Cygwin\bin
at the start of PATH and saved it. All aspects of LyX were uninstalled.
Then I installed LyX1.3.7pre5. If you try this you will find that the LyX
installer reports the full path to the executable. Some helper apps are
favored above all others. So the default is C:\Msys\1.0\bin which contains
both sh.exe and the also needed sed.exe. I deliberately chose the browse
button (which you can utilize with most these helper apps) and navigated
to C:\Cygwin\bin and chose it. Now LyX did not install because either the
sh.exe or sed.exe (or both) from Cygwin, is not the version that Lyx137_5
wants. It wants the Msys version. So I started over. This time I chose the
default C:\Msys\1.0\bin and the install succeeded, even though I had only
Cygwin in the PATH and no Msys in the PATH. The test machine is the
lucky one that installs LyX137_5, my most modern machine does not.
By 'favored' I think some apps may be hardwired. A better example is
gsview32.exe which is the gsviewer. I had Xemtex ahead of C:\Ghostgum\
gsview, in the Win PATH. LyX would not view postscript files. I ran
debug and found out that LyX was invoking the gsview32.exe which
resided deep in the XemTex sub-directory, and it wouldn't work. So I
changed Ghostgum\gsview to before XemTex in the Path and it worked.
I don't think that that is the meaning of what he said. For example,
if the PATH were searched the installer would have discovered that I
already have an sh.exe from cygwin, as this information is not found
in the registry.
Well, you don't want it to find the cygwin sh.exe. So lets change that
to you have Msys in your PATH. The LyX installer is invoking the
search, and the hint that the PATH provides, for the location of sh.exe
still needs to be confirmed on the *hard drive*. Because there is cruft
in both the registry and the PATH.
So the decision to search the PATH (which I thought Angus said
he didn't do) in evaluated in terms of efficiency. On 97 out of 100
systems (at least) there is no relevant information in the PATH, so
searching the PATH is a waste of time. On maybe 3 of the systems,
the search on the hard drive is slightly accelerated. Not a good tradeoff.
The hints for locating the relevant executable on the hard drive should
come from the LyX installer not the Windows PATH which rarely
contains such information to become a hint. I've read Angus comments
on code and I think it is quite likely this is implemented (could be wrong).
If there is no hint also in the registry, then searching the hard drive must
do. I agree that the registry is not a great source, but at least 90% of
Windows programs write to the registry. So there may be a good hint
which still needs to be confirmed. Compare this to searching the PATH
which will rarely contain a hint, and even if so, must still be confirmed.
By confirmed I mean verified to exist on the hard drive. It is complicated
by time issues when searching the registry in terms of rating efficiency.
I've just installed LyX without LyX or any helper applications in
the Windows PATH environment variable. And it works. So can
you tell me why it is "blindingly obvious" that LyX should first
ascertain that these things are already in the PATH?
One reason is that one above. Another is that I set my PATH in a
a certain way for a reason. For example, I want to replace a command
with another one of the same name and, to be sure that my command is
used, I put it ahead in the PATH (i.e., I put it in a directory which
is listed ahead in the PATH). If the lyx installer prepends to the
PATH the location of the command I do not want to use, I lose.
"One reason is that one above." SH: I don't see that your comment
which I replied to, demonstrates your conclusion for the 'reason above'.
You don't have to lose. The Angus model LyX1.3.7_5 comes fully
equipped with a browse button, the selection is not automatic. So
all you have to do is navigate to the identical directory which you
also want shown/duplicated in your PATH. You have to do this
with other versions of LaTeX which will also work with LyX.
[...]
SH: LyX1.3.6 works and it doesn't check/ascertain the PATH
variable and it was released prior to 1.3.7. So not checking the
PATH first is not the cause of the problem; is it supposed to
be "blindingly obvious" that checking the PATH should have
been used as a safety net? Even so, finding the executables
happens much earlier than outputting a too large \path_prefix.
So this part is not blindingly obvious to me because I don't see
it as following from his explanation, which seems reasonable.
------------------------------------------------------------------------------
He was not referring to the problem of the mangled PATH.
I hope that know the meaning of his "blindingly obvious" statement
is clear.
Well, it is more clear because Angus amplified upon it.
"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 ;-)"
Just in case you think I'm being rude in your direction, I'm not. The
"blindingly obvious" bit was aimed at myself.
SH: There are three terms I take issue with: "blindingly obvious", "first"
and "ascertain these things are already in the PATH".
"first" is easy. The LyX installer must search the hard drive, not the
PATH, to confirm the existence of certain helper program executables.
Not until it has that string consisting of found directory paths, can it
join the content of that string to the content of the PATH string. That
doesn't require a search of the PATH variable; Lyx is providing the
content of hard disk search which generates a string to be joined, later.
SH: I've just installed LyX without LyX or any helper applications in
the Windows PATH environment variable. And it works. So can
you tell me why it is "blindingly obvious" that LyX should first
ascertain that these things are already in the PATH?
<shrug>Whether you like it or not, these apps can be found in LyX's copy
of
the PATH, either from the global PATH or from the \path_prefix variable.
</shrug>
This is what I mean about changing the subject to something tangenital.
I specifically said "Windows PATH environment variable" why should
it be ascertained that these things are in the PATH.
I never say anything to deny the existence of LyX's copy of the PATH.
What I said is that you don't need a search of the Windows PATH in
order for the Win PATH string to be joined to the string which results
from LyX invoking a search of the hard drive. That doesn't involve
searching the Windows PATH. The two strings which will be merged
may have duplicate entries, but rarely unless the user manually pre-wrote
them. LyX does not write anything to the Windows PATH. IOW,
WinPATH = x, LyX finds some entries to write to its own PATH, = y,
and resultant is x+y and this requires no search of Windows PATH.
Copying and joing (like cat) is not equivalent to the term search.
The Win Path environment variable does not = x+y. I have extra 200+
characters in my configure file, and in my lyxrc.default file, which also
show up in my Lyx-->Edit-->preferences-->paths--Path prefix window.
Yes, it seems like a good idea that the 80 or so characters of a string
contributed by LyX which is the nucleus of the displayed \path_prefix
view should not be multiplied several times. But if you check the swollen
output against the input, you are not looking at the Win PATH string,
because nothing gets written to the Win Path string, but you would be
checking against the LyX contributed string of x+y. And I don't think
the word for such a check can be construed to "search". That is usually
described as comparing one string or list to another, producing a diff,
which represents an error in this case. The Win PATH portion, why
would it matter if it is copied "first"? Win Path is not altered by LyX, and
adding Win PATH to LyX's string is not identical to the Windows PATH.
Getting Win PATH and adding it to Lyx's string can be done later, not 1st.
Alan Kay was a bright genius and a computer programmer and pioneer.
He had enough modesty to state that any very complex computer program
must be checked for bugs because the human intellect is not sufficient to
cover all the bases. Even a bright programmer learns by experience. And
he cannot be expected to foresee and forestall all possible bugs. That is
why I think "blindingly obvious" shows an unrealistic appreciation of one's
human condition applied to this situation. And the idea that there is a need
to ascertain the Windows PATH, first, to check on excessive output, is an
expression of the human condition. Notice that in Physics, theories are
confirmed by physical experiments.
Hindsight,
Stephen
