subject:"textclass.lst"

- Original Message - 
From: "Enrico Forestieri" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, December 13, 2005 7:02 PM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]

Stephen Harris <[EMAIL PROTECTED]> writes:

I wish I were smarter so that it would be blindingly obvious to me too.
I envision four(5) scenarios:

I see that Angus already answered your questions.

I think that your doubts are due to a misconception of the PATH.
Please, have a look here http://www.robvanderwoude.com/which.html
where you can find a script that scans the PATH to find a command.

--
Enrico

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'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?

It is not that I disagree with his explanation; it is that his explanation
is not consistent with his initial claim, nor does it support that claim.

Angus: "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 ;-)

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.
--

And does checking the prepended LyX discovered executable
paths have to involve a comparison of the Windows Path
environment variable, or, perhaps some other variable could
store the information for later comparison with configure and
its output to \path_prefix?

This comment is speculative on my part, and perhaps a good
programmer could instantly dismiss this notion and say that
it is blindingly obvious that the Win  PATH should be employed
for this. I am really not going to defend this last speculation as
refuting any claim of blindingly obvious. It is my comments
above the dotted line that I think refute claims of a blindingly
obvious situation. I wanted to make that clear because of the
tendency of people to commit the logical fallacy of blowing
up a minor claim/speculation and responding to that instead
of the heart of the position. I am disputing the "blindingly
obvious" statement, not the later explanation which in this
particular case I largely already knew, unlike for instance Aspell.

When I earned my computer degree I received two A's in Linux
classes which means I am know about the 'which' command,
although my programming skills are comparitively weak. Now
I have two winxp pro computers, one of which installs 137pre5
and the other one doesn't, and they both have similar versions
of helper applications installed.

I find that perplexing and a nice troubleshooting challenge.

Regards,
Stephen

Re: There's Something About Textclass.lst [WinXP, installing into]

- Original Message - 
From: "Angus Leeming" <[EMAIL PROTECTED]>

To: 
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 t

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-13 Thread Enrico Forestieri

Stephen Harris <[EMAIL PROTECTED]> writes:
> 
> I wish I were smarter so that it would be blindingly obvious to me too.
> I envision four(5) scenarios:

I see that Angus already answered your questions.

I think that your doubts are due to a misconception of the PATH.
Please, have a look here http://www.robvanderwoude.com/which.html
where you can find a script that scans the PATH to find a command.

--
Enrico

Re: There's Something About Textclass.lst [WinXP, installing into]

Stephen Harris 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 ;-)

By which I meant that I should have done so yet didn't ;-)

> I wish I were smarter so that it would be blindingly obvious to me too.
> I envision four(5) scenarios:

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.

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.

> (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.

There is very little hard coding of the names of individual external
binaries within the LyX.exe binary. Obvious examples that are hard coded
are "sh.exe" and "python.exe" which are used to run *scripts* that *can*
by tuned by you if you wish. Examples would be "convertDefault.sh" and
"lyxpreview2ppm.py" or "lyx2lyx". 

LyX knows of all other external processes through its "converters" and
"viewers" which are defined in "lyxrc.defaults" and which can be tuned by
you (the tuning will be stored in your personal "preferences" file. 

Typical entries might be:
   \viewer pdf2 "acroread"
which says use acroread to view files in pdf2 format. Here "pdf2" is
defined as the result of a conversion process. In this case:
   \converter latex pdf2 "pdflatex $$i" "latex"

Similarly, to take your own particular example, "gsview" could reasonably
be defined as a viewer of "ps" format files, again where "ps" format files
are generated by a conversion process. Here
   \converter dvi ps "dvips -o $$o $$i" ""

Note that the conversion commands defined here do not tell LyX *where* to
look for a given executable. They tell LyX only *what* to look for. The
\path_prefix concept is the other half of the puzzle.

> Perhaps there are some benefits to using the PATH in addition
> to checking the registry, but they do not appear to me to be
> overwhelmingly obvious, sufficient to glaringly refute the inability
> to provide/add confirming evidence to the registry report that I've
> mentioned above.

LyX doesn't use the registry at all. LyX uses only the PATH environment
variable. That's not likely to change any time soon, although there *are*
plans to rewrite the LyX/Resources/lyx/configure script as a python script
(currently it's a Bourne shell script) that is capable of searching the
Registry. Ie, functionality currently in the Windows Installer and
therefore available only when you *install* LyX will be moved into the
configure script so that it's available when you *reconfigure* LyX.

> I think checking for the existence of the relevant executable on
> the hard drive with the registry, provides a lot more confirming
> evidence than the PATH, which purposely or accidentally may
> not have been written to during a LyX helper program installation.
> Though of course it would have a time trade-off.

Nonsense. Even Microsoft think that the registry was ultimately an error.
Moreover, the PATH concept works in a platform independent way on Windows,
Unix and Mac whereas the registry does not. 

> Quoting that poem -- I'm beginning to suspect you have Scot ancestry,

I do, but not on the side where the Angus comes from.

-- 
Angus

Re: There's Something About Textclass.lst [WinXP, installing into]

- Original Message - 
From: "Angus Leeming" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, December 13, 2005 11:11 AM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]

Stephen Harris wrote:

On my computer, the contents of \path_prefix are a subset of the
Windows PATH environment variable because I've manually added
them. Checking the contents of PATH and comparing it to LyX's
\path_prefix to determine accuracy seems awfully smart, like AI.

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 ;-)

I wish I were smarter so that it would be blindingly obvious to me too.
I envision four(5) scenarios:

1. A program has been uninstalled and neither the registry or PATH
trace was removed by the uninstall. There will be a high correlation
between these two events because it arises from a common cause,
a faulty uninstaller, so there is no independent confirmation. I think
it is obvious that there will be no additional benefit from ascertaining
that the program is in the PATH, in this case.

2. A program has been removed that removes its trace in the registry
but fails to erase its PATH entry (if it has been added). Should the
LyX installer decide that the program exists just from its PATH
entry? Probably not. If the answer is probably not, then the LyX
installer can decide to install the program just from the program's
lack of a registry entry. Ascertaining the PATH provides no extra
information, the decision is based on just the registry reporting in
this case also.

3. A program exists in the registry, that does not appear in the PATH.
This happens when the program is not manually added to the PATH,
and does not automatically write itself to the PATH. Not having a
corresponding PATH entry doesn't tell the LyX installer that the
program needs to be installed. Should the program be written to the
PATH based on this information in this case. Probably not. So
ascertaining the PATH does not provide additional information for
a decision.

4. A program exists in the registry and in the PATH. The PATH
confirms this case only when it will already work so there is no
additional information provided in this case; the PATH is not
doing something in this case to distinguish its input from the
cases when the PATH reports false positives. It just happens
to be aligned in this case.

(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.

I had an earlier version of ghostscript 8.13 which did not remove
itself from the registry and remained in the PATH. I'm pretty sure
that I've added C:\texmf and C:\localtexmf to the PATH manually.
I am not sure, but I don't think when I uninstalled Miktex in order to
test TexLive, that the uninstall of Miktex removed those directories
or removed them from the PATH. (perhaps a potential problem)

Perhaps there are some benefits to using the PATH in addition
to checking the registry, but they do not appear to me to be
overwhelmingly obvious, sufficient to glaringly refute the inability
to provide/add confirming evidence to the registry report that I've
mentioned above.

I think checking for the existence of the relevant executable on
the hard drive with the registry, provides a lot more confirming
evidence than the PATH, which purposely or accidentally may
not have been written to during a LyX helper program installation.
Though of course it would have a time trade-off.

[snip]

SH: Isn't he referring to his Windows PATH environment variable?

Yes. He means he's tweaked this from the Start menu. Any process that's
subsequently spawned will have access to a copy of the WindowsOS process'
environment variables.

If you can trim some items of the \path_prefix content because
"everything needed" is already in the Windows PATH, why can't
you trim all the items in \path_prefix if you have all of the contents
of \path_prefix already included in your Windows PATH variable?

You can. If LyX can find gswinc.exe already there's no need for
\path_prefix to tell it where gswinc.exe is.

I questioned his statement because I thought LyX relied on its own
\path_prefix and was independent of the Windows PATH for operation
of LyX function, not that LyX is independent of an OS, or a key part of
it. What does "... I already have everything needed in my path" mean?

Is this question now answered?

Yes, and you can be sure I tested it! Thanks for the detailed explanation.

Quoting that poem -- I'm beginning to suspect you have Scot ancestry,
Stephen

Re: There's Something About Textclass.lst [WinXP, installing into]

- Original Message - 
From: "Enrico Forestieri" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, December 13, 2005 9:17 AM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]

Angus Leeming <[EMAIL PROTECTED]> writes:

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

Angus, you did a wonderful job. I saw people which started using lyx on
windows only because now it was easily installable.

However, I always wondered why in your installer you did not simply check
for the existence of a command in the path before asking to install a
package, instead of always relying on the registry.

I suppose this is a limitation of that NSIS thing...

--
Enrico

I think finding the executable on the hard drive, like the Miktex install
does with latex.exe, would confirm reports from the registry or PATH
that the programs referred to, still actually exist. Maybe the configure
file could be checked so that it doesn't contain more than 200 characters,
which is probably less than the length of PATH. Trying to figure out
what programs do, for example using Xnview rather than ImageMagick
as an image converter for LyX, and distinguishing them for inclusion
in \path_prefix strains the bounds of a meaningful relationship. The
PATH and the registry are both unreliable as sources of information.
Neither get deleted reliably when programs are uninstalled by users,
so both can falsely report the existence of vanished programs/paths.

Regards,
Stephen

Re: There's Something About Textclass.lst [WinXP, installing into]

Stephen Harris wrote:
> On my computer, the contents of \path_prefix are a subset of the
> Windows PATH environment variable because I've manually added
> them. Checking the contents of PATH and comparing it to LyX's
> \path_prefix to determine accuracy seems awfully smart, like AI.

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 ;-)

>> 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).
>>
> By global PATH, do you mean Windows PATH is global and
> \path_prefix is local? Or that there is a LyX global path variable?

Think of an operating system as a tree of processes. Let's say that LyX is
launched from a cmd.exe terminal. This terminal is the parent to the
spawned LyX process. A *copy* of all environment variables visible to
cmd.exe is made available to the LyX process. This LyX process can modify
these environment variables as it sees fit, but won't alter the
environment variables (or their contents) that are visible to the parent,
cmd.exe process. Should the LyX process spawn its own child processes
(launching gswinc.exe, for example), then these child processes have
access to a *copy* of the environment variables available to LyX *at the
moment that the child was spawned*.

Thus, we use the lyxrc.defaults \path_prefix string to modify the local
copy of the PATH environment variable available to the LyX process.

> This is where I became confused.

Makes sense now?

> Enrico: Yes, I noticed it. Anyway, I always edit the configure script
> after
 installation to trim \path_prefix because I already have everything
 needed in my path.
> 
> SH: Isn't he referring to his Windows PATH environment variable?

Yes. He means he's tweaked this from the Start menu. Any process that's
subsequently spawned will have access to a copy of the WindowsOS process'
environment variables.

> If you can trim some items of the \path_prefix content because
> "everything needed" is already in the Windows PATH, why can't
> you trim all the items in \path_prefix if you have all of the contents
> of \path_prefix already included in your Windows PATH variable?

You can. If LyX can find gswinc.exe already there's no need for
\path_prefix to tell it where gswinc.exe is.

> I questioned his statement because I thought LyX relied on its own
> \path_prefix and was independent of the Windows PATH for operation
> of LyX function, not that LyX is independent of an OS, or a key part of
> it. What does "... I already have everything needed in my path" mean?

Is this question now answered?

>> What I propose to do is to add some text to the final screen of the
>> Installer:
[snip text...]

> This looks good. By tune automatically, do you mean if the user has
> exercised the option to choose an alternate installation directory?

That's exactly what I mean.

> The best laid plans of mice and men...,
> Stephen

The best laid schemes o' Mice an' Men,
Gang aft agley,
An' lea'e us nought but grief an' pain,
For promis'd joy!

Still, thou art blest, compar'd wi' me!
The present only toucheth thee:
But Och! I backward cast my e'e,
On prospects drear!
An' forward, tho' I canna see,
I guess an' fear!

-- 
Angus

Re: There's Something About Textclass.lst [WinXP, installing into]

Enrico Forestieri wrote:

> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
>> 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
> 
> Angus, you did a wonderful job. I saw people which started using lyx on
> windows only because now it was easily installable.
> 
> However, I always wondered why in your installer you did not simply check
> for the existence of a command in the path before asking to install a
> package, instead of always relying on the registry.
> 
> I suppose this is a limitation of that NSIS thing...

I don't think I can blame NSIS although I'd rather have my teeth pulled out
than use their scripting language.

I was probably behaving like a rabbit in front of an oncoming car when I
wrote the LyX installer; the blazing headlights (aka the registry) were so
new and frightening that I forgot about everything else. Result? Squashed
bunny.

-- 
Angus

Re: There's Something About Textclass.lst [WinXP, installing into]

- Original Message - 
From: "Angus Leeming" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, December 13, 2005 4:54 AM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]

Stephen Harris wrote:

- Original Message -
From: "Enrico Forestieri"
<[EMAIL PROTECTED]> To:
<[EMAIL PROTECTED]> Cc:
 Sent: Monday,
December 12, 2005 5:17 PM Subject: Re: There's Something About
Textclass.lst [WinXP, installing into]

because I think it is very likely that if you examine your 1.3.7pre5
configure file you'll see that the Path preview section is inflated
by a ~two hundred characters.

Yes, I noticed it. Anyway, I always edit the configure script after
installation to trim \path_prefix because I already have everything
needed in my path.

You mean your Windows path? I keep learning. I knew that
LyX would work with Path prefix alone, without any Lyx helper
programs in the Windows path, but I didn't know that one could
trim the path_prefix because it was already handled in the
Windows path.

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 ;-)

On my computer, the contents of \path_prefix are a subset of the
Windows PATH environment variable because I've manually added
them. Checking the contents of PATH and comparing it to LyX's
\path_prefix to determine accuracy seems awfully smart, like AI.

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).

By global PATH, do you mean Windows PATH is global and
\path_prefix is local? Or that there is a LyX global path variable?

This is where I became confused.

Enrico said he edited the configuration script after installation, which
is the first time as a user, I see it. At this point you can trim it down by
editing, so that it outputs a proper \path_prefix. Or you can use the old
1.3.6 configure script which contains the correct number of entries.

Enrico: Yes, I noticed it. Anyway, I always edit the configure script after

installation to trim \path_prefix because I already have everything
needed in my path.

SH: Isn't he referring to his Windows PATH environment variable?
What other path could he be referring to, that he can put in the path?
It doesn't help to edit the configure script after installation unless one
intends to run it in order to manage the content of \path_prefix?

If you can trim some items of the \path_prefix content because
"everything needed" is already in the Windows PATH, why can't
you trim all the items in \path_prefix if you have all of the contents
of \path_prefix already included in your Windows PATH variable?

I questioned his statement because I thought LyX relied on its own
\path_prefix and was independent of the Windows PATH for operation
of LyX function, not that LyX is independent of an OS, or a key part of it.
What does "... I already have everything needed in my path" mean?

Why not simply get an archive (zip, tar, whatever) of the 1.3.7pre5 LyX
directory and unpack it over a 1.3.6 installation? Thereafter, one could
simply edit the configure script to adjust \path_prefix, run "sh
configure"
and be done.

Well, maybe that would work, I wonder what Angus thinks? Since
I am only a computer technician rather than a developer, I can't
fully grasp all the ramifications of this approach; I always test,
test...

That's essentially what the Installer does. There's no magic to it.

So, yes, it'll work.

What I propose to do is to add some text to the final screen of the
Installer:

We know that sometimes this Installer fails to run the command
  sh configure
from the
  C:/Program Files/LyX/Resources/lyx
(I'll tune this automatically ;-)
directory. As a result various data files used by LyX are not generated 
and

lyx.exe will fail to run successfully.

If you find that the files lyxrc.defaults and textclass.lst in the above
directory do not exist or have zero size, then you should open up an MSYS
or CMD terminal and run the above command from the above directory.

One final note: you'll find a '\path_prefix' entry in lyxrc.defaults. It's
contents are prepended to the PATH environment variable visible to lyx.exe
and it's used to find the various binaries used by LyX (sh.exe,
gswinc.exe, python.exe, etc). It's been reported that sometimes the
Installer generates multiple redundant instances of individual entries in
'\path_prefix'. Feel free to edit manually.

Feel free to act as editor ;-)
--
Angus

This looks good. By tune automa

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-13 Thread Enrico Forestieri

Angus Leeming <[EMAIL PROTECTED]> writes:

> 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 

Angus, you did a wonderful job. I saw people which started using lyx on
windows only because now it was easily installable.

However, I always wondered why in your installer you did not simply check
for the existence of a command in the path before asking to install a
package, instead of always relying on the registry.

I suppose this is a limitation of that NSIS thing...

--
Enrico

Re: There's Something About Textclass.lst [WinXP, installing into]

Stephen Harris wrote:

> 
> - Original Message -
> From: "Enrico Forestieri"
> <[EMAIL PROTECTED]> To:
> <[EMAIL PROTECTED]> Cc:
>  Sent: Monday,
> December 12, 2005 5:17 PM Subject: Re: There's Something About
> Textclass.lst [WinXP, installing into]
> 
> 
>>> because I think it is very likely that if you examine your 1.3.7pre5
>>> configure file you'll see that the Path preview section is inflated
>>> by a ~two hundred characters.
>>
>> Yes, I noticed it. Anyway, I always edit the configure script after
>> installation to trim \path_prefix because I already have everything
>> needed in my path.
>>
> 
> You mean your Windows path? I keep learning. I knew that
> LyX would work with Path prefix alone, without any Lyx helper
> programs in the Windows path, but I didn't know that one could
> trim the path_prefix because it was already handled in the
> Windows path.

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).

>> Why not simply get an archive (zip, tar, whatever) of the 1.3.7pre5 LyX
>> directory and unpack it over a 1.3.6 installation? Thereafter, one could
>> simply edit the configure script to adjust \path_prefix, run "sh
>> configure"
>> and be done.

> Well, maybe that would work, I wonder what Angus thinks? Since
> I am only a computer technician rather than a developer, I can't
> fully grasp all the ramifications of this approach; I always test,
> test...

That's essentially what the Installer does. There's no magic to it.

So, yes, it'll work.

What I propose to do is to add some text to the final screen of the
Installer:

We know that sometimes this Installer fails to run the command
   sh configure
from the
   C:/Program Files/LyX/Resources/lyx
(I'll tune this automatically ;-)
directory. As a result various data files used by LyX are not generated and
lyx.exe will fail to run successfully.

If you find that the files lyxrc.defaults and textclass.lst in the above
directory do not exist or have zero size, then you should open up an MSYS
or CMD terminal and run the above command from the above directory.

One final note: you'll find a '\path_prefix' entry in lyxrc.defaults. It's
contents are prepended to the PATH environment variable visible to lyx.exe
and it's used to find the various binaries used by LyX (sh.exe,
gswinc.exe, python.exe, etc). It's been reported that sometimes the
Installer generates multiple redundant instances of individual entries in
'\path_prefix'. Feel free to edit manually.

Feel free to act as editor ;-)
-- 
Angus

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Stephen Harris

- Original Message - 
From: "Enrico Forestieri" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, December 12, 2005 5:17 PM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]

because I think it is very likely that if you examine your 1.3.7pre5
configure file you'll see that the Path preview section is inflated
by a ~two hundred characters.

Yes, I noticed it. Anyway, I always edit the configure script after
installation to trim \path_prefix because I already have everything
needed in my path.

You mean your Windows path? I keep learning. I knew that
LyX would work with Path prefix alone, without any Lyx helper
programs in the Windows path, but I didn't know that one could
trim the path_prefix because it was already handled in the
Windows path.

Or you could edit Path prefix later if you use the 1.3.7pre5
configure. Or maybe leave it as it may not cause damage and just
be a hidden unsightly blemish.

[...]

Your script is certainly hugely more elegant. I just thought to provide
a simple means, although hardly simpler (if the user already has sh.exe
in his Windows path) to complete his Lyx1.3.7pre5 install now. I was
able to follow the Angus advice for this. I hope I'm reinforcing it, 
while
your advice might be more suitable for inclusion in the installer 
package.

Why not simply get an archive (zip, tar, whatever) of the 1.3.7pre5 LyX
directory and unpack it over a 1.3.6 installation? Thereafter, one could
simply edit the configure script to adjust \path_prefix, run "sh 
configure"

and be done.

--
Enrico

Well, maybe that would work, I wonder what Angus thinks? Since
I am only a computer technician rather than a developer, I can't
fully grasp all the ramifications of this approach; I always test, test...

Nice to see you developing ideas,
Stephen

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Stephen Harris

- Original Message - 
From: "Paul A. Rubin" <[EMAIL PROTECTED]>

To: 
Sent: Monday, December 12, 2005 3:05 PM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]

Angus Leeming wrote:

Enrico Forestieri wrote:

Angus, what about a configure.bat script?

Y'know, sometimes the simplest ideas are the best ;-)

However, don't we need admin privileges to generate files in C:\Program
Files\LyX\Resources\lyx ?

Not positive, but I don't think so.  Whomsoever shall create that 
directory, yea verily shall he/she/it own it, and have all sorts of 
permissions in it.  I think (security on Windows has a stochastic 
element).  So if the batch file is run under the same login id that 
installed the software, it should work.  Maybe.  (An administrator could 
also run it.)

Paul

Well, we are talking about an ordinary user and they did not
create C:\program files, that is created during the initial install.
The initial install is where/when the admin password is created.

When I tested this with Nautilus, my toy test alterego, which
has standard user rights, I could not install LyX to 
C:\program files\Lyx , an error message was generated with
every attempted file install. 

I could install however, to C:\Lyx or E:\LyX with 1.3.6
(but earlier I wasn't able to install to the C:\ drive in one test)
I've read various developer opinion about why MS decided
to have a C:\Program files, instead of C:\programs or the
German C:\programme. Nearly everybody agrees that it was
either stupid or deliberate, with most thinking deliberate since
it causes problems with Linux ports. I think that at the least
the default LyX install should be C:\Lyx rather than adopting
Microsoft propaganda. Has anyone read of a solid reason for 
MS creating C:\program files? They are trying to force a habit.

The instructions that come with Miktex say to install to a
directory without spaces, and that is the default. 

Likewise, I don't think runas.exe works unless you have the
admin or maybe high authority user status, just like su. An
ordinary user cannot use it. If you can use it, you already
own sufficient permissions. There is going to be no security
breach that obvious. I have installed LyX 1.3.7pre5 into 
C:\LyX and C:\program files\Lyx and either way, one still

needs to run sh.exe configure. I also installed 1.3.7pre5
as Nautilus, an ordinary user. It would not install on the
C: drive. It would install on E:\LyX and sh.exe configure
also ran successfully, no admin rights needed. However,
it used python24 which I installed while acting as admin.
A current 137pre5 install can use python24 if it is already
installed, but I've read that a non-admin user can't install
python24(and maybe gsview) to start with, they have to
use Python23, which is no big deal. 

So if the batch file is run under the same login id that 
installed the software, it should work.  

True enough, but the ordinary user can't install to 
C:\program files to begin with, and maybe not to C:

although a batch file will work where you do manage
to install LyX. Curiously, the Lyx137 install on my 
C: drive with admin priveleges was 30.31~mb but the 
137pre5 install on the non-admin user, E: drive was 
39.37mb~ So the tests seem to support Angus' view.

Regards,
Stephen

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Enrico Forestieri

On Mon, 12 Dec 2005 13:42:19 -0800, Stephen Harris wrote:
> 
> This particular subject was about the Uwe .51 complete installer.
> The OP had already tried "sh.exe configure" and it didn't work.
> The OP does not have admin rights and that most likely is the
> problem.

I must have missed this bit. Then this is an entirely different problem.

> I do like your .bat idea. I have a configure file on my E: drive for
> 1.3.6 stable. The OP was able to install 1.3.6 because it does not
> require admin rights. I think he should utilize his 1.3.6 configure
> script and copy it to the 1.3.7pre5 Lyx\resource\lyx directory,
> because I think it is very likely that if you examine your 1.3.7pre5
> configure file you'll see that the Path preview section is inflated
> by a ~two hundred characters.

Yes, I noticed it. Anyway, I always edit the configure script after
installation to trim \path_prefix because I already have everything
needed in my path.

> Or you could edit Path prefix later if you use the 1.3.7pre5
> configure. Or maybe leave it as it may not cause damage and just
> be a hidden unsightly blemish.
> 
> I don't think gsview installs in the .51 series without admin rights.
> So I found one, preview, which is shareware that does not appear to
> use the registry: http://www.lib-sys.com/preview.htm

The gsview sources are freely available, so one could always compile by
itself a copy and place it wherever suits. However, I understand that this
may be hard for most users.

[...]
> .bat or .cmd files can be very useful in Windows as scripts are in Linux,
> and they are easy to create or modify slightly. So for instance your
> script uses Cygwin; the Windows default is sh.exe and sed.exe originating
> from C:\msys\1.0\bin so a less elegant batfile than yours could read, if a
> prefab configure.bat file is included in the lyx1.3.7pre5 package, which
> unpacks to the same directory as the installation directory (since the user
> might change the default from c:\program files\lyx, which has its configure
> in ~\lyx\resources\lyx). The user can also open and type from the dos
> prompt from the location he has chosen for the Lyx installation:
> (assuming default install directory for Msys)

Yes, scripts are much more versatile than binaries and they may be adapted
easily. The one I posted is that which I use. I didn't try to make it the
most general possible as anyone can build upon it and adapt it to own
needs. This is the spirit of free software, I think, and I fully agree
with it.

[...]
> Your script is certainly hugely more elegant. I just thought to provide
> a simple means, although hardly simpler (if the user already has sh.exe
> in his Windows path) to complete his Lyx1.3.7pre5 install now. I was
> able to follow the Angus advice for this. I hope I'm reinforcing it, while
> your advice might be more suitable for inclusion in the installer package.

Why not simply get an archive (zip, tar, whatever) of the 1.3.7pre5 LyX
directory and unpack it over a 1.3.6 installation? Thereafter, one could
simply edit the configure script to adjust \path_prefix, run "sh configure"
and be done.

--
Enrico

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Paul A. Rubin


Angus Leeming wrote:

Enrico Forestieri wrote:


Angus, what about a configure.bat script?



Y'know, sometimes the simplest ideas are the best ;-)

However, don't we need admin privileges to generate files in C:\Program
Files\LyX\Resources\lyx ?



Not positive, but I don't think so.  Whomsoever shall create that 
directory, yea verily shall he/she/it own it, and have all sorts of 
permissions in it.  I think (security on Windows has a stochastic 
element).  So if the batch file is run under the same login id that 
installed the software, it should work.  Maybe.  (An administrator could 
also run it.)


Paul

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Enrico Forestieri

Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> However, don't we need admin privileges to generate files in C:\Program
> Files\LyX\Resources\lyx ?
> 

I really don't know. My win2k came preinstalled on a FAT32 partition, so
I don't need privileges to write everywhere on disk, and I never used Windows
before last year. I need privileges only to perform administrative tasks
and recently I discovered the runas.exe command which changed my life ;-)
(it is a sort of "su user -c" command).

Anyway, I think that it cannot be worse than directly running sh.exe configure.
I don't know how the installer works, but couldn't it be a path problem?

--
Enrico

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Stephen Harris

- Original Message - 
From: "Enrico Forestieri" <[EMAIL PROTECTED]>

To: 
Sent: Monday, December 12, 2005 8:48 AM
Subject: Re: There's Something About Textclass.lst [WinXP, installing into]

Angus Leeming <[EMAIL PROTECTED]> writes:

From an MSYS terminal window (maybe even a cmd.exe one for all I know):

cd "C:/Program Files/LyX/Resources/lyx"
/sh.exe configure

That will generate the missing files.

Angus, what about a configure.bat script?

This particular subject was about the Uwe .51 complete installer.
The OP had already tried "sh.exe configure" and it didn't work.
The OP does not have admin rights and that most likely is the
problem.

I do like your .bat idea. I have a configure file on my E: drive for
1.3.6 stable. The OP was able to install 1.3.6 because it does not
require admin rights. I think he should utilize his 1.3.6 configure
script and copy it to the 1.3.7pre5 Lyx\resource\lyx directory,
because I think it is very likely that if you examine your 1.3.7pre5
configure file you'll see that the Path preview section is inflated
by a ~two hundred characters.

Or you could edit Path prefix later if you use the 1.3.7pre5
configure. Or maybe leave it as it may not cause damage and just
be a hidden unsightly blemish.

I don't think gsview installs in the .51 series without admin rights.
So I found one, preview, which is shareware that does not appear to
use the registry: http://www.lib-sys.com/preview.htm

Since ghostscript creates the .ps file, you only really need a viewer
to print the file and maybe save it to another location than Lyx's temp.
So I changed the LyX default temp dir in order to use this .bat file,
opening up a dos prompt and changing drives from the c:~~ prompt
by typing E:  (I installed LyX on E: in my non-admin rights test)

cd e:\preview\temp
cd lyx_tmpdir*
cd lyx_tmpbuf*
copy *.* e:\preview\temp
e:\preview\preview.exe

and one can use the file menu to open the contents of e:\pview\temp.
I clean up afterwards by using nuke.com, a common dangerous utility.

deleteps.bat:

E:\preview\nuke.com e:\preview\temp

md temp
(a screen will appear asking the user to type Y for yes/proceed)

Perhaps it can also solve the problem that the configure script is not
launched in 137pre5 at installation time (I also have this problem).

.bat or .cmd files can be very useful in Windows as scripts are in Linux,
and they are easy to create or modify slightly. So for instance your
script uses Cygwin; the Windows default is sh.exe and sed.exe originating
from C:\msys\1.0\bin so a less elegant batfile than yours could read, if a
prefab configure.bat file is included in the lyx1.3.7pre5 package, which
unpacks to the same directory as the installation directory (since the user
might change the default from c:\program files\lyx, which has its configure
in ~\lyx\resources\lyx). The user can also open and type from the dos
prompt from the location he has chosen for the Lyx installation:
(assuming default install directory for Msys)

config1.bat could contain a few simple alternatives:

1. C:\msys\1.0\bin\sh.exe configure (if config1.bat is in the same 
directory)

or
2. C:\msys\1.0\bin\sh.exe "C:\program files\lyx\resources\lyx\configure"
or
3. C:\msys\1.0\bin\sh.exe c:\lyx\resources\lyx\configure

The reason I went into this is just in case a current reader has this
problem which is solved with "sh.exe" configure, for a now fix.

They can open Notepad, copy and paste the correct line for their install,
change the default saving from .txt to "all files" and then use Save as
to name the config1.bat as they please (ending with .bat though) and
save it into the proper lyx\resources\lyx directory for their installation.
Open a dos prompt, navigate to the directory referred to above, and type
config1.bat  at the prompt. Actually you can run 2 or 3 from what-
ever directory you have saved config1.bat to, from the dos prompt, for
instance from C:\documents and settings\username  config1.bat 

Here is the one I use. It extracts the \path_prefix from configure to
properly set up the path before calling sh.exe configure.
Please, manually join the lines ending with \ to the line following them.
I had to resort to break them this way as the gmane interface does not let
me post lines longer than 80 chars.

8<8<8<8<8<8<8<
@echo off
if "%OS%"=="Windows_NT" goto win2k
goto usage

:win2k
setlocal enableextensions
if not exist "configure" goto noconf
if "%ComSpec%"=="" goto nocmd
if "%windir%"=="" goto nocmd

:: Make sure native windows commands are (initially) ahead in the path
for /f "usebackq tokens=* delims=" %%A in (`echo %ComSpec%`) do \
   set PATH=%windir%;%%~dpA;%PATH%

:: Extract \path_prefix from configure and prepend it to the path
for

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Angus Leeming

Enrico Forestieri wrote:
> Angus, what about a configure.bat script?

Y'know, sometimes the simplest ideas are the best ;-)

However, don't we need admin privileges to generate files in C:\Program
Files\LyX\Resources\lyx ?

-- 
Angus

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Enrico Forestieri

Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> From an MSYS terminal window (maybe even a cmd.exe one for all I know):
> 
> cd "C:/Program Files/LyX/Resources/lyx"
> /sh.exe configure
> 
> That will generate the missing files.

Angus, what about a configure.bat script?

Perhaps it can also solve the problem that the configure script is not
launched in 137pre5 at installation time (I also have this problem).

Here is the one I use. It extracts the \path_prefix from configure to
properly set up the path before calling sh.exe configure.
Please, manually join the lines ending with \ to the line following them.
I had to resort to break them this way as the gmane interface does not let
me post lines longer than 80 chars.

8<8<8<8<8<8<8<
@echo off
if "%OS%"=="Windows_NT" goto win2k
goto usage

:win2k
setlocal enableextensions
if not exist "configure" goto noconf
if "%ComSpec%"=="" goto nocmd
if "%windir%"=="" goto nocmd

:: Make sure native windows commands are (initially) ahead in the path
for /f "usebackq tokens=* delims=" %%A in (`echo %ComSpec%`) do \
set PATH=%windir%;%%~dpA;%PATH%

:: Extract \path_prefix from configure and prepend it to the path
for /f "usebackq tokens=2 delims= " %%A in (`type configure ^| \
find "path_prefix"`) do set pathprefix=%%A
set pathprefix=%pathprefix:"=%
set pathprefix=%pathprefix:\\=\%
set PATH=%pathprefix%;%PATH%

:: We are ready to launch configure
C:\cygwin\bin\sh.exe configure
goto end

:nocmd
echo.
echo Cannot find the command interpreter or the system dir.
goto end

:usage
echo.
echo This script works on Windows NT 4 / 2000 / XP
echo and performs a system wide configuration of LyX.
goto end

:noconf
echo.
echo Cannot find the configure script.

:end
if "%OS%"=="Windows_NT" endlocal
8<8<8<8<8<8<8<

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-12 Thread Angus Leeming

Tariq Kamal wrote:

> Hello!
> 
> I'm a relatively new user to LyX (installed it a couple of months ago
> in my laptop, and I've barely scratched the surface of its
> functionality). As it was, I figured that installing LyX into my work
> system would be a good idea. So I downloaded the
> LyXWin137preComplete-0-51.exe package for installation on my work PC
> (which runs Windows XP), and figured that it would not take more than
> half an hour to install, tops.
> 
> In retrospect, using the 1.37 release might have been a mistake. The
> first attempt, I ended up getting this message:
> 
> "LyX wasn't able to find any layout description!
> 
> Check the contents of the file "textclass.lst"
> Sorry, has to exit :-("
> 
> Right. So I checked textclass.lst, and this is what I saw:
> 
> ## This file declares layouts and their associated definition files.
> ## It has been automatically generated by configure
> ## Use "Options/Reconfigure" if you need to update it after a
> ## configuration change. Run ./configure manually to update the
> ## system wide version of this file.
> 
> That's it. Nothing else. The other LST file, packages.lst, is at 0
> bytes. I'm guessing that this isn't the normal state of affairs.
> 
> This situation has persisted, even after I did the following things:

>From an MSYS terminal window (maybe even a cmd.exe one for all I know):

cd "C:/Program Files/LyX/Resources/lyx"
/sh.exe configure

That will generate the missing files.

-- 
Angus

Re: There's Something About Textclass.lst [WinXP, installing into]

2005-12-11 Thread Stephen Harris

- Original Message - 
From: "Tariq Kamal" <[EMAIL PROTECTED]>

To: "LyX Users Mailing List" 
Sent: Sunday, December 11, 2005 11:28 PM
Subject: There's Something About Textclass.lst [WinXP, installing into]

Hello!

Everything so far has failed, and I've run out of ideas. What,
exactly, have I done wrong? What can I do to make it right again?

Massive thanks in advance,

Tariq Kamal

Sometimes the Lyx directory located at 
C:\documents and settings\yourusername\Application data\LyX
doesn't get uninstalled and it has to be done manually. I also use 
Control Panel --> Add/remove programs to install/remove LyX.

Worth a try,
Stephen

There's Something About Textclass.lst [WinXP, installing into]

2005-12-11 Thread Tariq Kamal

Hello!

I'm a relatively new user to LyX (installed it a couple of months ago
in my laptop, and I've barely scratched the surface of its
functionality). As it was, I figured that installing LyX into my work
system would be a good idea. So I downloaded the
LyXWin137preComplete-0-51.exe package for installation on my work PC
(which runs Windows XP), and figured that it would not take more than
half an hour to install, tops.

In retrospect, using the 1.37 release might have been a mistake. The
first attempt, I ended up getting this message:

"LyX wasn't able to find any layout description!

Check the contents of the file "textclass.lst"
Sorry, has to exit :-("

Right. So I checked textclass.lst, and this is what I saw:

## This file declares layouts and their associated definition files.
## It has been automatically generated by configure
## Use "Options/Reconfigure" if you need to update it after a
## configuration change. Run ./configure manually to update the
## system wide version of this file.

That's it. Nothing else. The other LST file, packages.lst, is at 0
bytes. I'm guessing that this isn't the normal state of affairs.

This situation has persisted, even after I did the following things:

1. Uninstalled and reinstalled LyX.
2. Uninstalled and reinstalled MiKTeX (I used the "Large" option after
the first time).
3. Uninstalled and reinstalled EVERYTHING associated with LyX (even
Perl, which I _know_ won't help).
4. Dug out the older 1.36ver1 package, and installed _that_ version
(after uninstalling LyX and reinstalling MiKTeX, and, at one point,
reinstalling MinSYS). Did steps 1 through 3 for that version as well.
5. Installed sed (the new version).
6. Ran "sh configure" in the ~\LyX\Resources\lyx\ directory.

Everything so far has failed, and I've run out of ideas. What,
exactly, have I done wrong? What can I do to make it right again?

Massive thanks in advance,

Tariq Kamal

--
Ia! Ia! Shub-Internet Fhtagn!
Ph'nglui mglw'nafh Shub-Internet
  Arlington County wgah'nagl fhtagn!
Ia! Ia! Shub-Internet Fhtagn!

Re: WinLyx 1.3.7pre4 install - missing textclass.lst

2005-11-29 Thread YOUNES Abdelrazak / M3SYSTEM


"Paul A. Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> YOUNES Abdelrazak / M3SYSTEM wrote:
> > One additional information: I have just installed Python 2.4.2. Maybe
this
> > is the problem?
> > Anyway, I have re-installed 1.3.6 and overwrite the bin directory with
the
> > one from 1.3.7pre4 installation. Seems to work fine...
> >
> > Thanks,
> > Abdel.
> >
> >
> > "YOUNES Abdelrazak (M3SYSTEM)"
> > <[EMAIL PROTECTED]>
wrote
> > in message
> >
news:[EMAIL PROTECTED]
> >
> >>Hello,
> >>
> >>I have a problem with the install of lyx 1.3.7pre4 (lyx-1.3.6 is OK). At
> >
> > the
> >
> >>install, a popup box says: Failed attempting to execute the configure
> >>script". I click on OK and let it launch but then a  new box  says:
> >>"Lyx wasn't able to find it's layout descriptions!"
> >>"Check that the file "textclass.lst" is installed correctly, Sorry, has
to
> >>exit :-("
> >>
> >>When I try at the command-line "lyx -x reconfigure" it gives me the same
> >>answer.
> >>
> >>Thanks,
> >>Abdel.
> >>
>
> Not sure, but we seem to be seeing some flaky symptoms from the
> 1.3.7pre4 installer.  If 1.3.6 works for you, presumably you have MinSys
> installed.  Usually the "no textclass.lst" syndrome is the result of not
> having a working sh.exe (or not having sed.exe), but if that were the
> case, you should not be able to install 1.3.6 either.

Right, MSIS is there and working.

>
> If you want to take another crack at 1.3.7, you might try opening a
> command window in the ...\Resources\lyx directory of the 1.3.7
> installation, and running 'sh configure' there.  (If the MinSys bin
> directory is not on your command path, you'll need to give a full path
> to sh.exe in the command line.)  That should generate textclass.lst,
> after which you should be able to start 1.3.7pre4.  Maybe.

That made it indeed. Thanks.

So I guess this is an installer bug...

Abdel

>
> Paul
>
>
>
>

Re: WinLyx 1.3.7pre4 install - missing textclass.lst

2005-11-29 Thread Paul A. Rubin


YOUNES Abdelrazak / M3SYSTEM wrote:

One additional information: I have just installed Python 2.4.2. Maybe this
is the problem?
Anyway, I have re-installed 1.3.6 and overwrite the bin directory with the
one from 1.3.7pre4 installation. Seems to work fine...

Thanks,
Abdel.


"YOUNES Abdelrazak (M3SYSTEM)"
<[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]


Hello,

I have a problem with the install of lyx 1.3.7pre4 (lyx-1.3.6 is OK). At


the


install, a popup box says: Failed attempting to execute the configure
script". I click on OK and let it launch but then a  new box  says:
"Lyx wasn't able to find it's layout descriptions!"
"Check that the file "textclass.lst" is installed correctly, Sorry, has to
exit :-("

When I try at the command-line "lyx -x reconfigure" it gives me the same
answer.

Thanks,
Abdel.



Not sure, but we seem to be seeing some flaky symptoms from the 
1.3.7pre4 installer.  If 1.3.6 works for you, presumably you have MinSys 
installed.  Usually the "no textclass.lst" syndrome is the result of not 
having a working sh.exe (or not having sed.exe), but if that were the 
case, you should not be able to install 1.3.6 either.


If you want to take another crack at 1.3.7, you might try opening a 
command window in the ...\Resources\lyx directory of the 1.3.7 
installation, and running 'sh configure' there.  (If the MinSys bin 
directory is not on your command path, you'll need to give a full path 
to sh.exe in the command line.)  That should generate textclass.lst, 
after which you should be able to start 1.3.7pre4.  Maybe.


Paul

Re: WinLyx 1.3.7pre4 install - missing textclass.lst

2005-11-29 Thread YOUNES Abdelrazak / M3SYSTEM

One additional information: I have just installed Python 2.4.2. Maybe this
is the problem?
Anyway, I have re-installed 1.3.6 and overwrite the bin directory with the
one from 1.3.7pre4 installation. Seems to work fine...

Thanks,
Abdel.


"YOUNES Abdelrazak (M3SYSTEM)"
<[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
> Hello,
>
> I have a problem with the install of lyx 1.3.7pre4 (lyx-1.3.6 is OK). At
the
> install, a popup box says: Failed attempting to execute the configure
> script". I click on OK and let it launch but then a  new box  says:
> "Lyx wasn't able to find it's layout descriptions!"
> "Check that the file "textclass.lst" is installed correctly, Sorry, has to
> exit :-("
>
> When I try at the command-line "lyx -x reconfigure" it gives me the same
> answer.
>
> Thanks,
> Abdel.
> 
>
> This message and any files transmitted with it are legally privileged and
intended for the sole use of the individual(s) or entity to whom they are
addressed. If you are not the intended recipient, please notify the sender
by reply and delete the message and any attachments from your system. Any
unauthorised use or disclosure of the content of this message is strictly
prohibited and may be unlawful.
>
> Nothing in this e-mail message amounts to a contractual or legal
commitment on the part of EUROCONTROL unless it is confirmed by
appropriately signed hard copy.
>
> Any views expressed in this message are those of the sender.
>
>

WinLyx 1.3.7pre4 install - missing textclass.lst

2005-11-29 Thread YOUNES Abdelrazak \(M3SYSTEM\)

Hello,

I have a problem with the install of lyx 1.3.7pre4 (lyx-1.3.6 is OK). At the
install, a popup box says: Failed attempting to execute the configure
script". I click on OK and let it launch but then a  new box  says:
"Lyx wasn't able to find it's layout descriptions!"
"Check that the file "textclass.lst" is installed correctly, Sorry, has to
exit :-("

When I try at the command-line "lyx -x reconfigure" it gives me the same
answer.

Thanks,
Abdel.


This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL unless it is confirmed by appropriately signed hard 
copy.

Any views expressed in this message are those of the sender.

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-16 Thread Paul A. Rubin


Stephen Harris wrote:



As I think Stephen said earlier, that would be indicative of a bad (or 
incomplete) LyX installation.  The LyX tree under Applications Data is 
created during installation (I'm pretty sure).  Saving a LyX document 
won't create it if it's not already there, and its absence may not 
affect the saving of the document.  Since we're pretty sure (?) the 
LyX configuration script is balking at a perceived lack of a working 
LaTeX executable, I wouldn't worry about this until after the MiKTeX 
issues are sorted out.




I think John first installed LyX 1.3.5. Was that under a different
c:\document and settings\...  path structure than is used currently?
Maybe a Preferences file under \username\ .lyx that needed deletion.

I mean delete \.lyx?


Version 1.3.5 and earlier did not put anything under Documents and 
Settings (nor under Program Files for that matter), since they were 
allergic to spaces in paths.  With 1.3.5, you designated a home 
directory, and a .lyx folder (with subfolders) was created thereunder, 
housing your preferences and customizations.  Version 1.3.6 looks 
specifically in Docs and Settings\your name here\Application Data, so 
there should be no collisions.  In fact, I've had 1.3.5 and 1.3.6 (and 
1.3.7, for that matter) peacefully coexisting on a couple of machines. 
1.3.6 has no idea the 1.3.5 preferences exist, and vice versa.


Paul

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-16 Thread Stephen Harris

- Original Message - 
From: "Paul A. Rubin" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, November 16, 2005 1:10 PM
Subject: Re: Installation Problem. All entries in Textclass.lst
are "false " so no output. Any suggestions?

BTW I have not been able to find a Lyx file in the Applications Data

file under User after I have installed, created and saved  a file in Lyx.
ARRGH!

As I think Stephen said earlier, that would be indicative of a bad (or 
incomplete) LyX installation.  The LyX tree under Applications Data is 
created during installation (I'm pretty sure).  Saving a LyX document 
won't create it if it's not already there, and its absence may not affect 
the saving of the document.  Since we're pretty sure (?) the LyX 
configuration script is balking at a perceived lack of a working LaTeX 
executable, I wouldn't worry about this until after the MiKTeX issues are 
sorted out.

I think John first installed LyX 1.3.5. Was that under a different
c:\document and settings\...  path structure than is used currently?
Maybe a Preferences file under \username\ .lyx that needed deletion.

I mean delete \.lyx?
Stephen

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-16 Thread Paul A. Rubin

John Kane wrote:

As far as I can tell my tex list matches the screen shot that you included.
I am unsure from your last posts if you want me to try the -e 
compatibiltiy mode however I gave it a try and

 >To force MiKTeX to use e-TeX in compatibility mode, follow these steps:
 >1. Run the MiKTeX options program, choose the TeX formats page, and
 >then for each program that you want in compatibility mode (e.g. latex,
pdflatex, etc.)  do the following:
 >2. Click on the Edit button,
 >3. Choose "e-TeX compatibility mode" as the compiler,
 >4. Click Apply,
5. Click Build"
Results of this is the same error message, as before, when trying an 
updatewhich comes down basically to

"initexmf: The file "latex.efmt" could not be found."
And as far as I can tell latex.efmt is not on my hard drive

On my system it's at C:\localtexmf\miktex\fmt\latex.efmt.  The fact that 
it's in the localtexmf tree suggests that it is created during 
installation or format updating, as opposed to being part of the 
original installation.

Incidentally, with a working MiKTeX installation you can locate this and 
other style/format/class files by opening a DOS prompt and running 
kpsewhich, to wit 'kpsewhich latex.eftm'.  It's generally faster than 
using the OS to search the entire MiKTeX directory tree (let alone the 
entire drive).

BTW I have not been able to find a Lyx file in the Applications Data 
file under User after I have installed, created and saved  a file in Lyx.

ARRGH!

As I think Stephen said earlier, that would be indicative of a bad (or 
incomplete) LyX installation.  The LyX tree under Applications Data is 
created during installation (I'm pretty sure).  Saving a LyX document 
won't create it if it's not already there, and its absence may not 
affect the saving of the document.  Since we're pretty sure (?) the LyX 
configuration script is balking at a perceived lack of a working LaTeX 
executable, I wouldn't worry about this until after the MiKTeX issues 
are sorted out.

From the Groping In The Dark Department:  Did you install MiKTeX from 
the Internet (as opposed to either a CD or a local network repository)? 
 If yes, you might try opening the MiKTeX Package Manager, waiting 
 for it to list all the packages, then syncing 
the directory (Repository->Synchronize) and checking for updates 
(Task->Update Wizard).  I've seen this used to resolve one or two 
miscellaneous installation bugs (which I think might have involved 
mixing older and newer MiKTeX components).

Paul

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-16 Thread John Kane

>>>Modern installs of LyX store the config "Lyx" directory under yourusername.>>I checked and it was not there before installation. Unfortunately it is  >>not there after either.>SH: If you have LyX installed now, then there is a new one there  >now or LyX is not installed. It is good that the old one is gone.>Paul had some hunch about pdfYes, I checked out his suggestion and my file looked okay.You mentioned a possible problem with R . I had uninstalled it so I  expect that it was not a problem but who knows. I'bm beginning to think  I should consult the augurs.  Sheep livers probably are just as  comprehensible as DOS error messages.  It also is an newer version  than the one mentioned in your mail    I have never loaded RWinEdt so it should not be a problem.  R  comes with a base installation and one can then load all sorts of  packages for
 it. RWinEdit is just one of them. I had never even heard  of it before. I may have to look into it :)  The current R-2.2.0  does not come with any .tex files that I can find.  Rd.sty currently resides in c:\Program  Files\R\R-2.2.0\share\texmf.  Exactly what this may mean I don't  know.  However it goes when I uninstall R which Idid  yesterday.  Of course it's back today. Takes all of 30 seconds to  install-almost as fast as MikTeX.  As far as I can tell my tex list matches the screen shot that you included.  I am unsure from your last posts if you want me to try the -e compatibiltiy mode however I gave it a try and   >To force MiKTeX to use e-TeX in compatibility mode, follow these steps:  >1. Run the MiKTeX options program, choose the TeX formats page, and  >then for each program that you want in compatibility mode (e.g. latex,  pdflatex, etc.)  do the following:  >2. Click on the Edit button,  >3. Choose
 "e-TeX compatibility mode" as the compiler,  >4. Click Apply,  5. Click Build"  Results of this is the same error message, as before, when trying an updatewhich comes down basically to   "initexmf: The file "latex.efmt" could not be found."  And as far as I can tell latex.efmt is not on my hard drive  BTW I have not been able to find a Lyx file in the Applications Data  file under User after I have installed, created and saved  a file  in Lyx.  ARRGH!  John Kane, Kingston ON  Canada
		Find your next car at Yahoo! Canada Autos

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-16 Thread Stephen Harris



Hello John, a major suggestion,

The problem with installing LyX may be a conflicting old *TeX.
I actually wrote this as a solution if you have R For Windows
installed which I think comes with RWinEdt. I'm speculating, so
if you don't, no need to read this. It is also somewhat of a summary.
I think that slighty older versions of R-Windows came with fpTeX.
And I noticed an R Folder under RWinEdt, and since you wrote:

"I have checked and could not find any  rogue Latex.exe files
and I have hunted down and exterminated the localtexmf and
texmf and the only texmf which was in my R folder. I simply
removed R for the moment. :)" [So I'm taking a chance for a fix.]

OTOH, if this post does not apply, I have not seen this topic
reported upon in this forum and a possible fix, so it may have
value by its addition to the mailing archives. Sent only to Lyx-users.

SH: This result came from Miktex Options, Update

Refresh ran okay
Update bombed
Cannot create the pdf latex format file
Cannot create the  plain TeX format file
Cannot create the latex2e format file
Cannot create the plain pdf format file.

SH: My working version of Miktex/Lyx has
the following non-excluded TeX Formats
pdfLaTeX
plain TeX
LaTeX2e (latex)
pdfTeX

SH: In the olden day I think they used c:\> initexmf --dump[=program]
For example:  initexmf --dump=tex

latex This creates the dump file latex.fmt which is used by latex.exe.

tex This creates the dump file plain.fmt which is used by tex.exe.

pdflatex This creates the dump file pdflatex.fmt which is used by
pdflatex.exe.

pdftex This creates the dump file pdftex.fmt which is used by pdftex.exe.

This suggests the following explanation applies:

http://www.murdoch-sutherland.com/Rtools/miktex.html

"e-TeX compatibility mode

To force MiKTeX to use e-TeX in compatibility mode, follow these steps:

1. Run the MiKTeX options program, choose the TeX formats page, and
then for each program that you want in compatibility mode (e.g. latex,
pdflatex, etc.)  do the following:

2. Click on the Edit button,

3. Choose "e-TeX compatibility mode" as the compiler,

4. Click Apply,

5. Click Build"

SH: I notice that a contributed package for R-Windows is RWinEdt.
I can run LyX, another TeX front-end and WinEdt, with MikTeX 2.4
(fpTex has bin-pdftex-1.20b-win32-static.zip 2005-01-16 9468 Kbyte
and RWinEdt also contains a file RW-LaTeX.png and latex directory.)
fpTex comes with the pdfTeX module. Another troubleshooter stated:

"I'm bothered by the fact that the output from your format
refresh seems to be running pdfetex rather than etex, but I
don't know if I should be."

SH: I'm a bit dubious that LyX is modular enough to fill in for
RWinEdt? But could RWinEdt still work with RWindows and
LyX serve for other publishing tasks? Is solution #4 needed?

"For one or two versions, MiKTeX has been ignoring the 
TEXINPUTS environment variable that most other TeX 
distributions use to indicate additions to the search path. 
The R make process uses TEXINPUTS to add 
$RHOME/share/texmf to the search path, so that

the Rd.sty style file will be found.

Instead of using TEXINPUTS, MiKTeX uses the command line option
"-include-directory=foo", to prepend foo to the search path.

There are four workarounds to this.

Workaround 4: Install the R style files into MikTeX. Remember to
re-install updates when you upgrade R! Instructions for this were
written by Gabor Grothendieck [a name of categorical Universe fame]:

1. Create a new tex subfolder of your \localtexmf folder:

   md \localtexmf\tex

2. Copy your R .sty and .fd files into it:


cd \Program Files\R\rw2001\share\texmf
copy *.* \localtexmf\tex

3. Go into

Start | Programs | MiKTeX | MiKTeX Options | General

and press Update Now and Refresh Now. (I am not certain that this step
needs to be done but it can't hurt.)

4. You can check whether it is finding Rd.sty in the right place with
the command:

findtexmf Rd.sty

#2 - #4 need to be repeated each time one installs a new version of R
if the *.sty or *.fd files have changed but if they have not changed
then nothing at all needs to be done. It has the advantage that it
leaves all MiKTeX options at their defaults and does not need a custom
miktex.ini file.

[Added in February, 2005]:
The most recent version of pdftex no longer supports TEXINPUTS,
even with the old *pdftex* engine, so Workaround 1 no longer works."

SH: I included this #4 step so you wouldn't have to look it up and
I'm going to send a copy. Should e-compatibility mode be used and
also Step #4? Can Lyx serve as a front-end for RWindows; can both
RWinEdt and Lyx be used at the same time if LyX can't do RWindows?
I think they probably can. pdfTeX seems to be a player in the drama.

I think it is a good idea to run both Miktex Options, Refresh & Update
after running etex compatibility mode first, and also after running step 4.
To leave no stone unturned run LyX --> Reconfigure also at the very end.
I think maybe that CreateRegistryPath patch for R

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-15 Thread Paul A. Rubin

Bugger. We're getting out of my depth on the LaTeX front.

The initex run was looking for the wrong file: should be 'initex
latex.ltx' (not .lts). The latex.ltx file should be in the
C:\MiKTeX\tex\latex\base directory (give or take adjusting the root path
of the MiKTeX install). Might be worth a try running that.

I'm bothered by the fact that the output from your format refresh seems
to be running pdfetex rather than etex, but I don't know if I should be.
When you ran latex against chklatex.ltx, it was (properly) etex that
ran, albeit unsuccessfully. One thing you could do just for the sake of
my curiosity is to take a look at the formats.ini file in the MiKTeX
config directory (sibling to the MiKTeX bin directory). In the section
labeled '[latex]', the compile should be 'etex' and the input should be
'latex.ltx'. It's a long-shot, but someone in the list encountered a
problem because 'latex.exe' was linked to pdflatex on his system.

You might want to take this to comp.text.tex on USENET, or to the help
forum for MiKTeX (http://www.miktex.org/fora.html).

Or you could try reposting here with a subject line like "MiKTeX
installation help" that might draw a guru. It's pretty clear that your
MiKTeX installation is broken, but I don't know why.

I'll be largely out of the loop until around 26 November, by the way.

Paul (who's brain is cramping)

John Kane wrote:

"Paul A. Rubin" <[EMAIL PROTECTED]> wrote:

John,

Did you try updating your format files using the MiKTeX Options program
(General tab, Format files section, Update Now button) and, if so, did
anything on your computer melt?

Paul

Arghh! I was afraid I'd forgotten something! Thanks. I just did it.

Results
Creating "latex.efmt"...

"pdfetex.exe" --ini --interaction=nonstopmode --halt-on-error --alias
pdflatex *\pdfcompresslevel=9 \pdfdecimaldigits=3 \pdfhorigin=1 true in \pdfoutput=1
\pdfpageheight=297 true mm \pdfpagewidth=210 true mm \pdfoptionpdfminorversion=4
\pdfpkresolution=600 \pdfvorigin=1 true in \input latex.ltx \dump
This is pdfeTeX, Version 3.141592-1.21a-2.2 (MiKTeX 2.4) (INITEX)
entering extended mode
(C:\texmf\tex\latex\base\latex.ltx (C:\texmf\tex\latex\00miktex\texsys.cfg)

!! No syntax for the current directory could be found

[EMAIL PROTECTED] set to: .

Assuming \openin and \input
have the same search path.

--And much more dreck-

John Kane wrote:

Updates on the continuing (non) installation saga
This replies to a number of postings by Steven and Paul over the Sunday 14 &
Nov 14, 2005. Hopefully I have not missed any important suggestions. I decided to
use Yahoo mail for the list since I don't use it much otherwise and thought it
would keep things separate. Unfortunately I had not realised the rather serious
limitations of it for handling a mail list.
Anyway
I did have an earlier installation of LyX Small a few weeks ago when I was
trying to install LyX 1.3.5. As far as I have been able to tell, there are no
files/folders left from that attempt. I spend a good while late yesterday and
this morning checking. Also checked for *.tex files and found nothing
suspicious.
Since then I have tried both the large and whole installations both from
the hard drive.
The last installation I also disabled my virus protection.
I have checked and could not find any rogue Latex.exe files and I have hunted
down and exterminated the localtexmf and texmf and the only texmf which was in
my R folder. I simply removed R for the moment. :)
I copied ltxcheck.tex to C:\texmf ran C:\texmf>latex ltxcheck.tex with the
same results as when I ran the 'latex chklatex.ltx' . That is, files not found
etc.
I then tried the c:\fmtutil –all with this result
C:\>fmtutil --all
'fmtutil' is not recognized as an internal or external
command,
operable program or batch file.

I tried “initex latex.lts Latex.lts does not seem to exist. A search of C drive did not find it.

C:\texmf>initex latex.lts
This is TeX, Version 3.141592 (MiKTeX 2.4) (INITEX)
! I can't find file `latex.lts'.
<*> latex.lts

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-15 Thread Stephen Harris

- Original Message - 
From: "John Kane" <[EMAIL PROTECTED]>

To: "Users LyX" 
Sent: Tuesday, November 15, 2005 2:26 PM
Subject: Re: Installation Problem. All entries in Textclass.lst
are "false " so no output. Any suggestions?

"Paul A. Rubin" <[EMAIL PROTECTED]> wrote:

John,

Did you try updating your format files using the MiKTeX Options program
(General tab, Format files section, Update Now button) and, if so, did
anything on your computer melt?

Paul

 Arghh! I was afraid I'd forgotten  something!  Thanks.  I just did it.

 Results
 Creating "latex.efmt"...
 "pdfetex.exe" --ini --interaction=nonstopmode --halt-on-error --alias 
pdflatex *\pdfcompresslevel=9 \pdfdecimaldigits=3 \pdfhorigin=1 true in 
\pdfoutput=1 \pdfpageheight=297 true mm \pdfpagewidth=210 true mm 
\pdfoptionpdfminorversion=4 \pdfpkresolution=600 \pdfvorigin=1 true in 
\input latex.ltx \dump

 This is pdfeTeX, Version 3.141592-1.21a-2.2 (MiKTeX 2.4) (INITEX)
 entering extended mode
 (C:\texmf\tex\latex\base\latex.ltx 
(C:\texmf\tex\latex\00miktex\texsys.cfg)

Is there actually a latex.ltx file in  (C:\texmf\tex\latex\base\latex.ltx ?
I think you need to run "initex latex.ltx" from above directory first, if
there is a latex.ltx file located there, and then run Miktex Options Update.

I would also play it safe and run LyX --> Edit --> Reconfigure
even if it may be a very unneeded step, or a devious and subtle riposte.

If for some reason you can't run initex latex.ltx first and then run
latex ltxcheck.tex second and get all Oks, that should narrow the
field of problem causes substantially.
I'll check on "preloaded format", unpacking and latex.dtx

 !! No syntax for the current directory could be found

I have both of those directories shown above installed on my computer.

I think the gremlin dongos may have et your latex.ltx,
Stephen

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-15 Thread John Kane

"Paul A. Rubin" <[EMAIL PROTECTED]> wrote:  

John,

Did you try updating your format files using the MiKTeX Options program 
(General tab, Format files section, Update Now button) and, if so, did 
anything on your computer melt?

Paul

  Arghh! I was afraid I'd forgotten  something!  Thanks.  I just did it.

  Results 
  Creating "latex.efmt"...
  "pdfetex.exe" --ini --interaction=nonstopmode --halt-on-error --alias  
pdflatex *\pdfcompresslevel=9 \pdfdecimaldigits=3 \pdfhorigin=1 true in  
\pdfoutput=1 \pdfpageheight=297 true mm \pdfpagewidth=210 true mm  
\pdfoptionpdfminorversion=4 \pdfpkresolution=600 \pdfvorigin=1 true in  \input 
latex.ltx \dump
  This is pdfeTeX, Version 3.141592-1.21a-2.2 (MiKTeX 2.4) (INITEX)
  entering extended mode
  (C:\texmf\tex\latex\base\latex.ltx (C:\texmf\tex\latex\00miktex\texsys.cfg)

  !! No syntax for the current directory could be found

  [EMAIL PROTECTED] set to: .

  Assuming \openin and \input 
  have the same search path.
  --And much more dreck-

John Kane wrote:
>   Updates on the continuing (non)  installation saga
>  This replies to a number of postings by Steven and Paul over the Sunday  14 
> & Nov 14, 2005. Hopefully I have not missed any important  suggestions. I 
> decided to use Yahoo mail for the list since I don't use  it much otherwise 
> and thought it would keep things separate.  Unfortunately I had not realised 
> the rather serious limitations of it  for handling a mail list.
>   Anyway
> I did have an  earlier installation of LyX Small a few weeks ago when I was 
> trying to  install LyX 1.3.5. As far as I have been able to tell, there are 
> no  files/folders left from that attempt. I spend a good while late  
> yesterday and this morning checking. Also checked for *.tex files and  found 
> nothing suspicious.
>   Since then I have tried both the large  and whole installations both 
> from the hard drive.
>   The last installation I also disabled  my virus protection.
>  I have checked and could not find any rogue Latex.exe files and I have  
> hunted down and exterminated the localtexmf and texmf and the only  texmf 
> which was in my R folder. I simply removed R for the moment. :)
>  I copied ltxcheck.tex to C:\texmf ran C:\texmf>latex ltxcheck.tex  with the 
> same results as when I ran the 'latex chklatex.ltx' . That is,  files not 
> found etc.
>   I then tried the c:\fmtutil  all  with this result
>   C:\>fmtutil --all
> 'fmtutil' is not  recognized as an internal or external 
> command,
>   operable program or  batch file.
> 
>   
> I tried initex latex.lts  Latex.lts  does not seem to exist. A search of 
> C drive did not find it.
>C:\texmf>initex latex.lts
> This is TeX, Version  3.141592 (MiKTeX 2.4) (INITEX)
> ! I can't find file  `latex.lts'.
> <*> latex.lts
> 

-
Find your next car at Yahoo! Canada Autos

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-15 Thread Paul A. Rubin

John,

Did you try updating your format files using the MiKTeX Options program
(General tab, Format files section, Update Now button) and, if so, did
anything on your computer melt?

Paul

John Kane wrote:

Updates on the continuing (non) installation saga
This replies to a number of postings by Steven and Paul over the Sunday 14
& Nov 14, 2005. Hopefully I have not missed any important suggestions. I
decided to use Yahoo mail for the list since I don't use it much otherwise and
thought it would keep things separate. Unfortunately I had not realised the
rather serious limitations of it for handling a mail list.
Anyway
I did have an earlier installation of LyX Small a few weeks ago when I
was trying to install LyX 1.3.5. As far as I have been able to tell, there are
no files/folders left from that attempt. I spend a good while late yesterday
and this morning checking. Also checked for *.tex files and found nothing
suspicious.
Since then I have tried both the large and whole installations both from
the hard drive.
The last installation I also disabled my virus protection.
I have checked and could not find any rogue Latex.exe files and I have
hunted down and exterminated the localtexmf and texmf and the only texmf which
was in my R folder. I simply removed R for the moment. :)
I copied ltxcheck.tex to C:\texmf ran C:\texmf>latex ltxcheck.tex with
the same results as when I ran the 'latex chklatex.ltx' . That is, files not
found etc.
I then tried the c:\fmtutil –all with this result
C:\>fmtutil --all
'fmtutil' is not recognized as an internal or external
command,
operable program or batch file.

I tried “initex latex.lts Latex.lts does not seem to exist. A search of C drive did not find it.

C:\texmf>initex latex.lts
This is TeX, Version 3.141592 (MiKTeX 2.4) (INITEX)
! I can't find file `latex.lts'.
<*> latex.lts

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-15 Thread John Kane

  Updates on the continuing (non)  installation saga
  This replies to a number of postings by  Steven and Paul over the Sunday 
14 & Nov 14, 2005. Hopefully I  have not missed any important suggestions. I 
decided to use Yahoo  mail for the list since I don't use it much otherwise and 
thought it  would keep things separate. Unfortunately I had not realised the  
rather serious limitations of it for handling a mail list.
  Anyway
  I did have an earlier installation of  LyX Small a few weeks ago when I 
was trying to install LyX 1.3.5. As  far as I have been able to tell, there are 
no files/folders left from  that attempt. I spend a good while late yesterday 
and this morning  checking.  Also checked for *.tex files and found nothing 
suspicious.
  Since then I have tried both the large  and whole installations both from 
the hard drive.
  The last installation I also disabled  my virus protection.
  I have checked and could not find any  rogue Latex.exe files and I have 
hunted down and exterminated the  localtexmf and texmf and the only texmf which 
was in my R folder. I  simply removed R for the moment. :)
  I copied ltxcheck.tex to C:\texmf ran  C:\texmf>latex ltxcheck.tex with 
the same results as when I ran  the 'latex chklatex.ltx' .  That is, files not 
found etc.
  I then tried the c:\fmtutil  all  with this result
  C:\>fmtutil --all
'fmtutil' is not  recognized as an internal or external 
command,
  operable program or  batch file.

  
I tried initex latex.lts  Latex.lts  does not seem to exist. A search of C 
drive did not find it.
   C:\texmf>initex latex.lts
This is TeX, Version  3.141592 (MiKTeX 2.4) (INITEX)
! I can't find file  `latex.lts'.
<*> latex.lts

  You suggested that I try printing  outside the LyX environment but I have not 
 a clue how to do this.  Nothing re printing etc can be seen in the View menu.  
As noted  before I cannot print or export except in ASCII. Custom export leaves 
 me with a blank command line.  Should I be able to type in a command?  
  I just noticed from the mailing list  that a new LyX installer is out.  I 
may bring in the exterminators  again, sanitize the machine and give it a try.
  Thanks for all the help so far. I  certainly have learned a lot (most of 
it useful :)  and recalled a  bunch of DOS commands I would happily had remain 
forgotten.
  John Kane, Kingston ON  Canada

  
  


-
Find your next car at Yahoo! Canada Autos

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-14 Thread Stephen Harris

- Original Message - 
From: "Paul A. Rubin" <[EMAIL PROTECTED]>

To: 
Sent: Monday, November 14, 2005 8:41 AM
Subject: Re: Installation Problem. All entries in Textclass.lst are "false " 
so no output. Any suggestions?

You got the same result as me so our approaches must be the same while 
John has strayed from the righteous path,

and I'm looking for some small difference in our steps.

Your logic is sound, but there are some wild-cards out there (for 
instance, an anti-virus program selectively interfering with his 
installation).

Cheers,
Paul

Thanks for taking the time to make a detailed response.
I'm sure John will succeed is he just doesn't give up.
Google reported not building a latex.fmt file during setup
was a problem with Miktex and the symptom was Miktex
trying to rebuild the formatting like his webpage link. But
the last report I saw was in 2004. I saw a report of an old
.emacs file causing one problem, solvable by changing the
location of Cygwin in the path.

Poetic Diction is not blind,
Stephen

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-14 Thread Paul A. Rubin


Stephen Harris wrote:

I'm wondering if John might have done a net install in which he didn't 
download the files first with setup.exe

and then run setup.exe again to build the installation.
That is how I ran the Miktex install, how did you do it?


I did it three different ways on three different machines.  On one, I 
downloaded the "minimal" installer, ran setup, then downloaded selected 
packages using the package manager.  On a second, I downloaded the 
larger installer and ran that.  On a third, I installed from a CD-R on 
which I'd burned the installation files from one of the first two.


If John bypassed storing the files and then installing, the net install 
might miss a file or run just a little askew. Seems like he should know 
if he had an old *tex version install.


Seems unlikely to me that the MiKTeX installer might skip or lose an 
essential cab file and not throw up an error message, but I've worked in 
the Windoze world long enough to believe just about anything bad is 
possible.  As for the older version, I thought he alluded in one post to 
upgrading a prior MiKTeX installation, but I might have hallucinated that.


You got the same result as me so our approaches must be the same while 
John has strayed from the righteous path,

and I'm looking for some small difference in our steps.


Your logic is sound, but there are some wild-cards out there (for 
instance, an anti-virus program selectively interfering with his 
installation).


Cheers,
Paul

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-13 Thread Stephen Harris

- Original Message - 
From: "Paul A. Rubin" <[EMAIL PROTECTED]>

To: 
Sent: Sunday, November 13, 2005 1:13 PM
Subject: Re: Installation Problem. All entries in Textclass.lst 
are "false " so no output. Any suggestions?

Paul

I'm wondering if John might have done a net install in 
which he didn't download the files first with setup.exe

and then run setup.exe again to build the installation.
That is how I ran the Miktex install, how did you do it?

If John bypassed storing the files and then installing, the 
net install might miss a file or run just a little askew. Seems 
like he should know if he had an old *tex version install.

You got the same result as me so our approaches must be 
the same while John has strayed from the righteous path,

and I'm looking for some small difference in our steps.

Regards,
Stephen

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-13 Thread Stephen Harris

- Original Message - 
From: "Stephen Harris" <[EMAIL PROTECTED]>

To: 
Sent: Sunday, November 13, 2005 3:29 PM
Subject: Re: Installation Problem. All entries in Textclass.lst are "false " 
so no output. Any suggestions?

I'll read up on latex.fmt,
Stephen

I copied latex.ltx from the base directory into the parent
texmf directory because I didn't want to take a chance
on producing a copy of latex.fmt which overwrote the
existing file. The command is "initex latex.ltx" which
then produced a latex.fmt file. The output of the process
looked very much like the output which John produced at
http://ca.geocities.com/jrkrideau/LyX/LatexLog12nov05.pdf
latex.fmt is an executable type file with those weird squiqqleys.

I think John should try this and compare it to my result. It is a
bit long so I will send an attachment to him apart from the list.
I'm a bit worried that it won't work because of a malevolent
presence sabotaging the best laid plans of mice and men.

Scotts Steinbeck,
Stephen

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-13 Thread Stephen Harris

- Original Message - 
From: "Paul A. Rubin" <[EMAIL PROTECTED]>

To: 
Sent: Sunday, November 13, 2005 1:13 PM
Subject: Re: Installation Problem. All entries in Textclass.lst are "false " 
so no output. Any suggestions?

2.  I've attached the file used to test your LaTeX

installation. and run 'latex chklatex.ltx'.  It should cough up a
log file, that should contain the string 'ThisIsLaTeX2e'
(lack of spaces intentional).

I ran the 'latex chklatex.ltx' file.  No sign of 'ThisIsLaTeX2e' as far 
as I can see. The log is at

http://ca.geocities.com/jrkrideau/LyX/LatexLog12nov05.pdf
.

Roger that.  For comparison purposes, here is what I get on my system:

--- log begins ---
This is e-TeX, Version 3.141592-2.2 (MiKTeX 2.4) (preloaded format=latex 
2005.11.4)  13 NOV 2005 15:56

entering extended mode
**chklatex.ltx
(chklatex.ltx
LaTeX2e <2003/12/01>
Babel  and hyphenation patterns for english, dumylang, 
nohyphenation, ge

rman, ngerman, french, loaded.

ThisIsLaTeX2e )
Here is how much of TeX's memory you used:
 6 strings out of 95901
 56 string characters out of 1195189
 44793 words of memory out of 1048577
 3139 multiletter control sequences out of 6
 3640 words of font info for 14 fonts, out of 100 for 2000
 14 hyphenation exceptions out of 4999
 5i,0n,1p,49b,8s stack positions out of 5000i,500n,1p,20b,32768s

No pages of output.
--- log ends ---

This is what I get also though the direct output was slightly different.

So something seems amiss with MiKTeX, and if I had to guess I would say 
that there is a configuration file somewhere that has developed an 
unfortunate sense of humor.  Unfortunately, my knowledge of LaTeX in 
general and MiKTeX in particular does not go very far beyond the funky 
capitalizations thereof.  I note that my log mentions a preloaded format 
and yours does not.  You might try running the MiKTeX Options program from 
the Start menu, clicking the Update Now button on the general tab. If you 
upgraded an old MiKTeX (as the paragraph below suggests) and did not 
rediddle the formats, things could get dicey.  (I had font generation go 
on hiatus until I did a format refresh.)

Well, the installation not building a format file (latex.fmt) is looking 
more

likely. John's log file ends with "initexmf: The file "latex.efmt" could not
be found. cannot make latex.efmt I can't find the default format file!"

I read of another problem with the format file caused in this
case of fptex .4 for windows being overinstalled by fptex .4.

Thank you Prof. Ripley.  I'll bet it is the .fmt file(s). Isn't
there a way to just rebuild the formats w/o a complete make/remake

Yes, sure :

c:\>fmtutil --all

It depends on what you have installed, but clearly, you have a 0.4
format file found by your 0.5 installation. [for windows fptex]
Fabrice

SH: But John didn't mention he had a prior version of *tex installed.

The annoying thing is that I spend an hour and a half
downloading and installing a new copy of MiKTeX and I
thought that I had manged to kill off everything from
the old installation. Well another clean sweep
tomorrow or Monday and I'll see what happens.

Try the update thingy first, lest the re-re-install waste time.

Well, it has the merit of being quick and painless.
Miktex options, refresh database and fonts etc.

Before installing LyX  I checked and all of the above
programs loaded including latex.exe.

According to computer I also had gswview which also
loaded.
C:\GSTools\gsview (gsview32.exe)

This all looks copacetic.  > Paul

It looks like the cure is to eliminate any conflict with
creating a working format file, I think called latex.fmt.
Sometimes installing over a prior version doesn't seem
to hurt at all and other times its a recipe for disaster.
There have been no other reports of problems with the
Miktex "large" install. Not everybody used small or total.

I'll read up on latex.fmt,
Stephen

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-13 Thread Paul A. Rubin


John Kane wrote:

From a DOS prompt, try the following:


1.  Type 'path' to get the system path.  Make sure that 

>>(a) the MiKTeX  bin directory is properly listed and (b) no directory

ahead of it contains a file named latex.exe.


Appears not to: Path is 
c:\program

files\imagemagick-6.2.5-q16;C:\Perl\bin\;C:\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Common Files\MDL Shared\ISIS;C:\msys\1.0\bin

and I don't see anything in texmf or miktex  that
looks suspicious


The output you posted shows that you are executing the latex.exe 
provided by MiKTeX, which confirms the lack of suspects here.



2.  I've attached the file used to test your LaTeX
installation. and run 'latex chklatex.ltx'.  It should cough up a
log file, that should contain the string 'ThisIsLaTeX2e'
(lack of spaces intentional).


I ran the 'latex chklatex.ltx' file.  No sign of 
'ThisIsLaTeX2e' as far as I can see. The log is at

http://ca.geocities.com/jrkrideau/LyX/LatexLog12nov05.pdf
. 


Roger that.  For comparison purposes, here is what I get on my system:

--- log begins ---
This is e-TeX, Version 3.141592-2.2 (MiKTeX 2.4) (preloaded format=latex 
2005.11.4)  13 NOV 2005 15:56

entering extended mode
**chklatex.ltx
(chklatex.ltx
LaTeX2e <2003/12/01>
Babel  and hyphenation patterns for english, dumylang, 
nohyphenation, ge

rman, ngerman, french, loaded.

ThisIsLaTeX2e )
Here is how much of TeX's memory you used:
 6 strings out of 95901
 56 string characters out of 1195189
 44793 words of memory out of 1048577
 3139 multiletter control sequences out of 6
 3640 words of font info for 14 fonts, out of 100 for 2000
 14 hyphenation exceptions out of 4999
 5i,0n,1p,49b,8s stack positions out of 5000i,500n,1p,20b,32768s

No pages of output.
--- log ends ---

So something seems amiss with MiKTeX, and if I had to guess I would say 
that there is a configuration file somewhere that has developed an 
unfortunate sense of humor.  Unfortunately, my knowledge of LaTeX in 
general and MiKTeX in particular does not go very far beyond the funky 
capitalizations thereof.  I note that my log mentions a preloaded format 
and yours does not.  You might try running the MiKTeX Options program 
from the Start menu, clicking the Update Now button on the general tab. 
 If you upgraded an old MiKTeX (as the paragraph below suggests) and 
did not rediddle the formats, things could get dicey.  (I had font 
generation go on hiatus until I did a format refresh.)



The annoying thing is that I spend an hour and a half
downloading and installing a new copy of MiKTeX and I
thought that I had manged to kill off everything from
the old installation. Well another clean sweep
tomorrow or Monday and I'll see what happens. 


Try the update thingy first, lest the re-re-install waste time.  Someone 
once said the definition of insanity is doing the same thing repeatedly 
but expecting different results.  They obviously were not installing 
software when they wrote that (or else equated installing software with 
insanity, which might not be entirely incorrect).


Below is a quick summary of what I think I have at the
moment.

Thanks for all the help. I get the feeling that this
may not be impossible after all.

Installed files and paths 


Actual according to the LyX installer
C:\msys\1.0\bin (sh.exe)
C:\Python23 (Python.exe)
C:\texmf\miktex\bin (latex.exe)
C:\Perl\bin (Perl.exe)
C:\Program Files\gs\gs8.51\bin  (gswin32c.exe)
C:\Program Files\ImageMagick-6.2.5-Q16  (convert.exe)
C:\LyX

Before installing LyX  I checked and all of the above
programs loaded including latex.exe.

According to computer I also had gswview which also
loaded.
C:\GSTools\gsview   (gsview32.exe)


LyX path after installation
C:\msys\1.0\bin;C:\Python23;C:\texmf\miktex\bin;C:\Perl\bin;C:\Program
Files\gs\gs8.51\bin;C:\Program
Files\ImageMagick-6.2.5-Q16

I added the gsview path and reconfigured. New LyX 
paths

C:\msys\1.0\bin;C:\Python23;C:\texmf\miktex\bin;C:\Perl\bin;C:\Program
Files\gs\gs8.51\bin;C:\Program
Files\ImageMagick-6.2.5-Q16;C:\GSTools\gsview

Systems Paths
c:\program
files\imagemagick-6.2.5-q16;C:\Perl\bin\;C:\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Common Files\MDL Shared\ISIS;C:\msys\1.0\bin



This all looks copacetic.  I should have mentioned earlier that (IIRC) 
you have to install Ghostscript before you install Ghostgum.  If you did 
them in the opposite order, that might explain your registry adventure 
(although I think if you try to install Ghostgum first it just punts). 
Also, once upon a time LyX users on Windows experienced major problems 
if Ghostscript was installed in a path containing spaces (for instance, 
under Program Files).  I ended up installing it under C:\gs (after 
trying it under Program

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-12 Thread John Kane

--- "Paul A. Rubin" <[EMAIL PROTECTED]> wrote:

> John Kane wrote:
> 
> > Obviously, as a student you, did not have the card
> > reader  shred your  computer deck ½ hours before
the
> > assignment was due and all you needed was a clean
> > printout.
> 
> No, but I have the dubious distinction of having
> rested a box of punch cards on the roof of my car
whilst unlocking it, and
> then driving off  without bringing them into the
car. 
> (Unsurprisingly, the cards did not  drive off as far
as I did.  Something about inertia,
> I believe.)

Simply a human factors problem. I was the victim of
the blind malevolence of  an IBM keypunch machine.
What a way to start a Monday!  I am still traumatized.

> > I've posted the log and a screen shot of the
directory 
>>
athttp://ca.geocities.com/jrkrideau/LyX/sh_configure_output1.pdf

> Well, the output from the configuration script is in
fact interesting. Note the first three lines.

Yes I thought they looked ominous but I didn't know
what to do about them except re-install MiKTex.

> Best to double check things here.  From a DOS>
prompt, try the following:
> 
> 1.  Type 'path' to get the system path.  Make sure
that (a) the MiKTeX  bin 
> directory is properly listed and (b) no directory
ahead of it  contains a file named latex.exe.

Appears not to: Path is 
c:\program
files\imagemagick-6.2.5-q16;C:\Perl\bin\;C:\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Common Files\MDL Shared\ISIS;C:\msys\1.0\bin

and I don't see anything in texmf or miktex  that
looks suspicious

> 
> 2.  I've attached the file used to test your LaTeX
> installation. and run 'latex chklatex.ltx'.  It
should cough up a
> log file, that should contain the string
'ThisIsLaTeX2e'
> (lack of spaces 
>  If  not, there may be a  problem with the MiKTeX
installation.  If that does
> work, then we will  need to do a small bit of
surgery to the installation script to find out 
> why it doesn't like your latex.exe file.

I ran the 'latex chklatex.ltx' file.  No sign of 
'ThisIsLaTeX2e' as far as I can see. The log is at
http://ca.geocities.com/jrkrideau/LyX/LatexLog12nov05.pdf
. 
The annoying thing is that I spend an hour and a half
downloading and installing a new copy of MiKTeX and I
thought that I had manged to kill off everything from
the old installation. Well another clean sweep
tomorrow or Monday and I'll see what happens. 

Below is a quick summary of what I think I have at the
moment.

Thanks for all the help. I get the feeling that this
may not be impossible after all.

Installed files and paths 

Actual according to the LyX installer
C:\msys\1.0\bin (sh.exe)
C:\Python23 (Python.exe)
C:\texmf\miktex\bin (latex.exe)
C:\Perl\bin (Perl.exe)
C:\Program Files\gs\gs8.51\bin  (gswin32c.exe)
C:\Program Files\ImageMagick-6.2.5-Q16  (convert.exe)
C:\LyX

Before installing LyX  I checked and all of the above
programs loaded including latex.exe.

According to computer I also had gswview which also
loaded.
C:\GSTools\gsview   (gsview32.exe)

LyX path after installation
C:\msys\1.0\bin;C:\Python23;C:\texmf\miktex\bin;C:\Perl\bin;C:\Program
Files\gs\gs8.51\bin;C:\Program
Files\ImageMagick-6.2.5-Q16

I added the gsview path and reconfigured. New LyX 
paths
C:\msys\1.0\bin;C:\Python23;C:\texmf\miktex\bin;C:\Perl\bin;C:\Program
Files\gs\gs8.51\bin;C:\Program
Files\ImageMagick-6.2.5-Q16;C:\GSTools\gsview

Systems Paths
c:\program
files\imagemagick-6.2.5-q16;C:\Perl\bin\;C:\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Common Files\MDL Shared\ISIS;C:\msys\1.0\bin

__ 
Find your next car at http://autos.yahoo.ca

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-12 Thread Paul A. Rubin


John Kane wrote:


Obviously, as a student you, did not have the card
reader  shred your  computer deck ½ hours before the
assignment was due and all you needed was a clean
printout.


No, but I have the dubious distinction of having rested a box of punch 
cards on the roof of my car whilst unlocking it, and then driving off 
without bringing them into the car.  (Unsurprisingly, the cards did not 
drive off as far as I did.  Something about inertia, I believe.)



I have installed R, OpenOffice.org, Endnote and a few
other things on this machine so I assume I have
administrator's rights.  


Seems likely.


 Post myresults.txt so we can see if  something went
splat.

Splat.  Looks remarkably like what I saw when I
installed LyX.  I just did not know how to capture the
text flow before. 


I've posted the log and a screen shot of the directory
at
http://ca.geocities.com/jrkrideau/LyX/sh_configure_output1.pdf



Well, the output from the configuration script is in fact interesting. 
Note the first three lines.  The configuration script will look first 
for latex.exe and then, if necessary, for latex2e.exe, searching your 
system command path each time.  If it finds either, it will test the 
program's functionality on a dummy LaTeX document file.  Unfortunately, 
if a broken version of latex.exe is found, the script moves on to 
latex2e.exe, rather than continuing to search the command path.


Note that the script apparently found a latex.exe program but decided it 
was not usable (i.e., broken), then moved on to latex2e.exe, which it 
never found.  Lack of latex2e.exe is normal, but no working latex.exe 
means no joy using LyX.  So the next question to investigate is why it 
thought the copy of latex.exe it found was not usable.


If I recall correctly, you ran 'latex --version' using the latex.exe 
file in the MiKTeX bin directory and got a valid answer from it, which 
would suggest that it in fact works (although there might still be set 
up problems with the classes, I suppose).  When I've encountered this 
particular pathology in the past, it has usually been because the user 
had installed something else (Cygwin in my case) that contained an 
older, broken or improperly installed latex.exe, and that was ahead of 
the correct latex.exe on the command path.  I did not mention this 
before because you posted your command path and I saw the MiKTeX bin 
directory on it fairly early (and in particular ahead of anything likely 
to contain latex.exe).


Best to double check things here.  From a DOS prompt, try the following:

1.  Type 'path' to get the system path.  Make sure that (a) the MiKTeX 
bin directory is properly listed and (b) no directory ahead of it 
contains a file named latex.exe.


2.  I've attached the file used to test your LaTeX installation.  Plop 
it down anywhere except your MiKTeX bin directory, cd to that directory, 
and run 'latex chklatex.ltx'.  It should cough up a log file, and the 
log file should contain the string 'ThisIsLaTeX2e' (lack of spaces 
deliberate) after the initial heading stuff.  If not, there may be a 
problem with the MiKTeX installation.  If that does work, then we will 
need to do a small bit of surgery to the installation script to find out 
why it doesn't like your latex.exe file.


Paul

\nonstopmode\makeatletter
\ifx\undefined\documentclass\else
  \message{ThisIsLaTeX2e}
\fi
\@@end

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-12 Thread Stephen Harris

- Original Message - 
From: "John Kane" <[EMAIL PROTECTED]>

To: 
Sent: Friday, November 11, 2005 12:30 PM
Subject: Re: Installation Problem. All entries in Textclass.lst are "false "
so no output. Any suggestions?

SH asked:  Have you installed ghostgum?

No I am getting a failure on that. See my later
posting on that. I seem to be having a problem getting
GSview to write to the registry.

I tried to find the error message "failed to add ps file association"
on Google and couldn't. Perhaps it does relate to permissions or
a prior setting. Speculating, do you have a postscript printer that
might have usurped the .ps file suffix (maybe network printer)?
I suppose you have tried making a new file association prior with
Windows Explorer/Tools/Folder Options prior to trying to install
GSview, though I am not sure that will help. Is there a prior ps file
association from the Ghostscript install or administrative fiat?

Never seen sech a confounded sight in all my dognabbed days,
Stephen

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

2005-11-11 Thread Stephen Harris

- Original Message - 
From: "John Kane" <[EMAIL PROTECTED]>

To: "Users LyX" 
Sent: Friday, November 11, 2005 3:27 PM
Subject: Re: Installation Problem. All entries in Textclass.lst are "false " 
so no output. Any suggestions?

--- "Paul A. Rubin" <[EMAIL PROTECTED]> wrote:

John Kane wrote:
>> I think you said that the MinSYS bin directory
>>(c:\msys\1.0\bin?) was on the LyX internal path
>
> No it was not.  I've added it. Still getting the

error

> after restarting LyX

That's not surprising.  Have you tried

Edit->Reconfigure after adding it

to the LyX path?
>
  > But DOS is not that far removed from punch
cards!

Which worked admirably, and hence had to be
superseded by something > newer and less reliable.

Obviously, as a student you, did not have the card
reader  shred your  computer deck ½ hours before the
assignment was due and all you needed was a clean
printout.

I have installed R, OpenOffice.org, Endnote and a few
other things on this machine so I assume I have
administrator's rights.

And also LyX. I think the problem may be more basic.
Installing both programs, Ghostscript and then Ghostview.

If you celebrate both Thanksgivings, you can have moose as
the main course of one dinner and wolverine at the second.

Regards,
Stephen

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

--- "Paul A. Rubin" <[EMAIL PROTECTED]> wrote:
> John Kane wrote:
> >> I think you said that the MinSYS bin directory  
> >>(c:\msys\1.0\bin?) was on the LyX internal path 
> > 
> > No it was not.  I've added it. Still getting the
error
> > after restarting LyX
> 
> That's not surprising.  Have you tried
Edit->Reconfigure after adding it 
> to the LyX path?
> > 
>   > But DOS is not that far removed from punch
> cards!
> 
> Which worked admirably, and hence had to be
> superseded by something > newer and less reliable.

Obviously, as a student you, did not have the card
reader  shred your  computer deck ½ hours before the
assignment was due and all you needed was a clean
printout.

I have installed R, OpenOffice.org, Endnote and a few
other things on this machine so I assume I have
administrator's rights.  

 Post myresults.txt so we can see if  something went
splat.

Splat.  Looks remarkably like what I saw when I
installed LyX.  I just did not know how to capture the
text flow before. 

I've posted the log and a screen shot of the directory
at
http://ca.geocities.com/jrkrideau/LyX/sh_configure_output1.pdf

> Not really.  You can find an ample supply of
> wolverines on the  University of Michigan campus
(Ann Arbor, MI, USA). 

Oh yes,  of course,  msu.edu!   I suppose the ritual
sacrifice of one or two Wolverines is a monthly
occurrence in Lancing (sp?).  My mother went to WMU
and a cousin graduated from your shop.

Thanks for the time and help.  

__ 
Find your next car at http://autos.yahoo.ca

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?


John Kane wrote:
I think you said that the MinSYS bin directory  
(c:\msys\1.0\bin?) was on the LyX internal path 



No it was not.  I've added it. Still getting the error
after restarting LyX


That's not surprising.  Have you tried Edit->Reconfigure after adding it 
to the LyX path?



 > But DOS is not that far removed from punch cards!

Which worked admirably, and hence had to be superseded by something 
newer and less reliable.


Another related question:if you click Help->LaTeX configuration in 
LyX, what do you see for the following:  the date
the file was generated 



I get “???”



the date of the LaTeX version (section 1);



I get “???”



which standard classes were found (section 3 -- each
class has a Found: yes/no entry)?



I get “???” for all classes


Ok, that confirms that the configuration script failed to run.  The 
usual causes are among the following:  it couldn't find sh, grep or sed 
(presumably remedied by adding the msys\1.0\bin directory to the LyX 
path); you had a bad (old) version of sed (ruled out in your case by 
using MinSYS 1.0); the configuration script failed to find a working 
copy of latex.exe (unlikely given that the MiKTeX bin directory is on 
your system path and you got the latex version number when you tested 
it); or the configuration results got written to an inaccessible 
directory.  The last one would likely involve some sort of permissions 
issue with your "personal" application data directory.


If you have not tried Edit->Reconfigure since adding the msys\1.0\bin 
directory to the LyX internal path prefix, that is the next order of 
business.  If that fails to resolve things, open a DOS window in the 
directory where the configure script lives and run 'sh configure > 
myresults.txt' there.  It should run now that the msys\1.0\bin directory 
is on your system path (you did add it there as well, via My Computer, 
right?).  Post myresults.txt so we can see if something went splat.





I checked to local stores and not a wolverine to be
seen. Would a fisher do?


Not really.  You can find an ample supply of wolverines on the 
University of Michigan campus (Ann Arbor, MI, USA).  It's also the state 
animal of Michigan, but IIRC it's not indigenous, so I suppose the ones 
at UM are out-of-state students.


Paul

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?


John Kane wrote:



Simply, that is because in this case the command needs
to be typed  from the command prompt at


C:\LyX\Resources\LyX> C:\msys\1.0\bin\sh.exe configure

OH, the long (and thankfully)  forgotten joys of DOS.
Absolute paths!

But it still does not work.  See
http://ca.geocities.com/jrkrideau/LyX/sh_configure_error.pdf
for a screen shot.


I'm guessing you did this before you added the msys\1.0\bin directory to 
the system path.  The not found messages would be because grep.exe and 
sed.exe are in the same directory with sh.exe.  The absolute path lets 
it find sh but is of no assistance with grep and sed.







Have you installed ghostgum?



No I am getting a failure on that. See my later
posting on that. I seem to be having a problem getting
GSview to write to the registry. 


I looked at the screen-shot you posted of the Ghostgum installer's 
death-rattle.  It looks as though you're right; it appears to have 
installed Ghostgum but failed while attempting to set file associations 
in the registry.  Are you an administrator on your machine?  If not, you 
may need to have someone with administrator rights do the installation.


In any case, if the only thing that gorked was the file associations, 
that's not critical.  You need file associations in order to 
double-click a .ps file and have GSView open automatically, but LyX does 
not rely on that.  If GSView was added to your Start menu, try starting 
it from there.  If not, try opening a DOS prompt in the C:\Program 
Files\Ghostgum\gsview directory and running 'gsview32'.  If GSView 
starts, you're in business; add it to the LyX application path 
(Edit->Preferences->Paths->PATH prefix).  Might not be a bad idea to add 
the directory the system path as well.  If GSView works but the 
installer never got around to creating shortcuts on the Start menu, we 
can remedy that manually.  (Obviously, the best thing would be if we 
could get it to install correctly.  If you're not a system admin on your 
machine, I would definitely try enlisting one's help.)


Paul



 


You ran from LyX, Edit --> Reconfigure  ? after


putting c:\ghostgum\gsview in the


Lyx path prefix? You need both ghostgum and


ghostscript. I saw Paul question this also:

No since I never got gsview to install.



You're seeing them in LyX via View->TeX


Information?  That's


inconsistent with the textclass not found


messages> (assuming that


textclass XX is in the TeX Information list).


John replied:


Yes, they are appearing in  View->TeX Information. 


I


.now have entries for all three categories and


following Steven's advice I have checked and


confirmed> that they also are present in the


directory ( I did a


dir *cls and got 10 files.)


SH: Those .cls files are spread out through the


c:\texmf


and the subdirectories beneath. I think the best way
is to run Windows Search, use *.cls for the files to
find  and focus the search on c:\texmf; that will


find and


report .cls in sub-directories of c:\texmf also
There should be 50 or 60 cls files reported under
TeX Information if you scroll down.



Yes they are there. The 10 were just the ones in one
subdir. I should have mentioned that.

Thanks for the dir > dir.txt advice.  







__ 
Find your next car at http://autos.yahoo.ca

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

--- "Paul A. Rubin" <[EMAIL PROTECTED]> wrote:
> John Kane wrote:
> > Path=C:\Perl\bin\;c:program
files\imanemagick-6.2.5_q16;C:\texmf\miktex\bin;c:\WINDOWS\system32;C:WINDOWS;C;\WINDOWS\System32\Wbem;C:Program
> > Files\Common Files\MDL Shared\ISIS
> 
> I'm getting a bit out of sync with what you put in
your replies to 
> Stephen, but I think you said that the MinSYS bin
directory 
> (c:\msys\1.0\bin?) was on the LyX internal path 

No it was not.  I've added it. Still getting the error
after restarting LyX

> > I'd forgotten there even were things like Paths. I
> > have not seen a DOS prompt since I bought a Mac
back
> > in 1988.
> 
> Well, there's your problem.  Macs stimulate use of
the 
>righthemisphere of your brain, probably to the
detriment of the left
> hemisphere.  Windows requires extensive use of the
left
> hemisphere, which among other  things controls the
utterance of >foul language.

But DOS is not that far removed from punch cards!  Oh
well at least I missed CP/M


> > BTW is there some way to pipe that DOS
> > stuff to a text file?  I copied that Path info by
> > hand. 
> 
> Yes, 
Thanks, it is good to see that DOS had progressed in
the 15 year since I suffered it.  

> 
> Back to the textclass XX is not found messages.
>Are you getting that 
> when you start LyX, when you try to create a new
> document in LyX, or what?  

I am getting it when 
a) I open a help document
b) When I open a document I have created and saved.

I do not get it when I create a new document.

> Another related question:if you click Help->LaTeX 
configuration in 
> LyX, what do you see for the following:  the date
> the file was generated 

I get ???

>the date of the LaTeX version (section 1);

I get ???

> which standard classes were found (section 3 -- each
> class has a Found: yes/no entry)?

I get ??? for all classes

> >>(On a side note, have> you considered 
> >>sacrificing a small furry animal to the gods of 
> >>computing before installing things?  Works for
> me.)
> > 
> > Small furry animal be damned, I'm considering
> > something like a black bear.  I'm a bit too far 
south
> > for a moose.
> 
> Just as well, antlers don't burn well.  Just avoid
> endangered species. 
> Wolverines always make good sacrifices, by the way
> (not to mention  they're not of much use otherwise).

I checked to local stores and not a wolverine to be
seen. Would a fisher do?

Thanks for the help.

John Kane, Kingston ON  Canada






__ 
Find your next car at http://autos.yahoo.ca

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

--- Stephen Harris <[EMAIL PROTECTED]> wrote:

> - Original Message - 
> From: "John Kane" <[EMAIL PROTECTED]>
> To: "Paul A. Rubin" <[EMAIL PROTECTED]>; "Users LyX"
> 
> Sent: Friday, November 11, 2005 8:57 AM
> Subject: Re: Installation Problem. All entries in
> Textclass.lst are "false " 
> so no output. Any suggestions?

> > --- "Paul A. Rubin" <[EMAIL PROTECTED]> wrote:
> >> John Kane wrote:
> >
> >> Assuming sh works, you might try running the
configure script in the DOS
> >> window.  Change to the directory C:\Program
> >> Files\LyX\Resources\lyx,
> >> verify that a file named 'configure' is there,
and
> >> then execute 'sh configure'.
> >>That runs the configuration script.
> >
> > Does not work
>
> Simply, that is because in this case the command
needs
> to be typed  from the command prompt at
C:\LyX\Resources\LyX> C:\msys\1.0\bin\sh.exe configure

OH, the long (and thankfully)  forgotten joys of DOS.
Absolute paths!

But it still does not work.  See
http://ca.geocities.com/jrkrideau/LyX/sh_configure_error.pdf
for a screen shot.

> You'll notice from the screen capture shcfg1.jpg 
that I have
> a file named textclass.lst (289) Do you have this
> file?

Yes I do
> 
> There is a textclass.lst error message that meansthe
> whole install failed. It sounds to me that have LyX
> installed if you can run LyX's View-->TexInformation
> and you are talking about generating a document?

Generating a document?  Well I opened a new document
typed in a line of text and saved it. Somewhere along
that line I checked the  LyX's View -->Tex 
Information and got the lists.
I still get an error message if I reopen the document.

> Also when I ran that C:~.\sh.exe configure it 
tampered  with my LyX configuration and I received an
error
> message: "LyX wasn't able to find any layout
description!
> Check the contents of the file "textclass.lst"
Sorry, has
> to exit." I thought you were reporting a similar 
error.

No not at all. I cannot even get the sh.exe to work

> Anyway easy enough to fix. I need to drag that Lyx
directory from C:\documents and settings\etc\etc
> into the Recycle Bin, uninstall LyX, and then run
the  installation again.
> 
> Of course you may recall I said that I have to add 
the function of gsview32.exe  (LyX tends to miss
that.)
> By going to Edit -->Preferences -->Path --> Path >
prefix
> and adding C:\ghostgum\gsview to the path statement
c:\ghostgum\gsview\ contains gsview32.exe
> Have you installed ghostgum?

No I am getting a failure on that. See my later
posting on that. I seem to be having a problem getting
GSview to write to the registry. 

 
> You ran from LyX, Edit --> Reconfigure  ? after
putting c:\ghostgum\gsview in the
> Lyx path prefix? You need both ghostgum and
ghostscript. I saw Paul question this also:

No since I never got gsview to install.

> 
> >>You're seeing them in LyX via View->TeX
Information?  That's
> >>inconsistent with the textclass not found
messages> (assuming that
> >>textclass XX is in the TeX Information list).
> 
> John replied:
> 
>> Yes, they are appearing in  View->TeX Information. 
I
>>.now have entries for all three categories and
following Steven's advice I have checked and
>> confirmed> that they also are present in the
directory ( I did a
>> dir *cls and got 10 files.)
> 
> SH: Those .cls files are spread out through the
c:\texmf
> and the subdirectories beneath. I think the best way
> is to run Windows Search, use *.cls for the files to
> find  and focus the search on c:\texmf; that will
find and
> report .cls in sub-directories of c:\texmf also
> There should be 50 or 60 cls files reported under
> TeX Information if you scroll down.

Yes they are there. The 10 were just the ones in one
subdir. I should have mentioned that.

Thanks for the dir > dir.txt advice.  






__ 
Find your next car at http://autos.yahoo.ca

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

John Kane wrote:

Path=C:\Perl\bin\;c:program
files\imanemagick-6.2.5_q16;C:\texmf\miktex\bin;c:\WINDOWS\system32;C:WINDOWS;C;\WINDOWS\System32\Wbem;C:Program
Files\Common Files\MDL Shared\ISIS

I'm getting a bit out of sync with what you put in your replies to
Stephen, but I think you said that the MinSYS bin directory
(c:\msys\1.0\bin?) was on the LyX internal path
(Edit->Preferences->Paths->PATH prefix in LyX). If not, it would be a
good idea to add it there and click Save. In any event, it's probably a
good idea to add it to your system path (this is why 'sh configure'
failed). To do that right-click on My Computer, click Properties, click
on the Advanced tab, click Environment Variables, highlight PATH in
either the user variables window or the system variables window, click
edit, prepend 'c:\msys\1.0\bin;' to the path, and then OK your way back
to reality. The only difference between user variables and system
variables is that the former adds it to the path only when you are
logged in and the latter adds it when anybody is logged in. Once done,
you should be able to run 'sh configure' from a DOS prompt in the
appropriate directory.

I'd forgotten there even were things like Paths. I
have not seen a DOS prompt since I bought a Mac back
in 1988.

Well, there's your problem. Macs stimulate use of the right hemisphere
of your brain, probably to the detriment of the left hemisphere.
Windows requires extensive use of the left hemisphere, which among other
things controls the utterance of foul language.

BTW is there some way to pipe that DOS
stuff to a text file? I copied that Path info by
hand.

Yes, you can issue a command such as 'path > mypath.txt' (of course,
then you have to figure out where mypath.txt wound up). Also, if you
need to copy stuff (such as error messages) out of a DOS window, you can
left-click the "system" button in the far left corner of the title bar
(where the Apple icon would be if this were a Mac, only this looks like
a C:\ prompt), then click Edit->Mark, highlight what you want and hit
Enter. That copies the highlighted text to the clipboard, from whence
it can be pasted into, among other things, a mail message.

Back to the textclass “XX” is not found messages. Are you getting that
when you start LyX, when you try to create a new document in LyX, or
what? (I'm trying to reconcile that with the fact that the TeX
Information window shows them.) Have you tried
Edit->Preferences->Reconfigure in LyX (after which you have to close and
restart LyX to benefit from any newly found classes)? This does the
same as 'sh configure', except you don't get any feedback about how
things are going.

Another related question: if you click Help->LaTeX configuration in
LyX, what do you see for the following: the date the file was generated
(third line of the file); the date of the LaTeX version (section 1); and
which standard classes were found (section 3 -- each class has a Found:
yes/no entry)?

That's likely to be a consequence of not installing
rather than an indication of the root cause. Does it give any
indication prior to that of why it's not installing?

Not that I have seen so far. It looks okay to me (but
what do I know?) until it simply reports that it
cannot add the file association. The log is at
http://ca.geocities.com/jrkrideau/LyX/GSinstallscript.pdf
if you want to take a look.

Will check this when time permits (i.e., after pretending to do some work).

(On a side note, have> you considered
sacrificing a small furry animal to the gods of
computing before installing things? Works for me.)

Small furry animal be damned, I'm considering
something like a black bear. I'm a bit too far south
for a moose.

Just as well, antlers don't burn well. Just avoid endangered species.
Wolverines always make good sacrifices, by the way (not to mention
they're not of much use otherwise).

Paul

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

--- "Paul A. Rubin" <[EMAIL PROTECTED]> wrote:
> John Kane wrote:
> > The file is there, all 43K of it, but sh
configure
> > simply gives me an error message
> > 'sh' is not recognized as an internal or external
> > command, operable program or batch file.
> 
> Ok, when you ran the first test (that worked 
correctly), were you in the 
> msys\1.0\bin directory? 

Yes

>If so, then the combination
> of that working and 
> the attempt to run the configure script not working
> would suggest that 
> the MinSYS bin directory is not on your command
> path.  I thought, from 
> your previous post, that it was, but just to double
> check, what do you 
> get if you type 'path' at a command prompt?

Path=C:\Perl\bin\;c:program
files\imanemagick-6.2.5_q16;C:\texmf\miktex\bin;c:\WINDOWS\system32;C:WINDOWS;C;\WINDOWS\System32\Wbem;C:Program
Files\Common Files\MDL Shared\ISIS

I'd forgotten there even were things like Paths. I
have not seen a DOS prompt since I bought a Mac back
in 1988.BTW is there some way to pipe that DOS
stuff to a text file?  I copied that Path info by
hand. 

>> I am
> > still getting the error message that the textclass
> > XX is not found but I now at least can see them
in
> > the TeX Information list.
> 
> You're seeing them in LyX via View->TeX Information?
>  That's  inconsistent with the textclass not found
messages (assuming that 
> textclass XX is in the TeX Information list).

Yes, they are appearing in  View->TeX Information.  I
now have entries for all three categories and
following Steven's advice I have checked and confirmed
that they also are present in the directory ( I did a
dir *cls and got 10 files.)

> > 
> > I am unable to print. I did manage to export an
ASCII
> > file!!.  
> 
> That's a positive step, but since ASCII export does>
not involve LaTeX, 
> it's a small positive step.
> > 
> > I finally managed to download GSview and it is now
> > refusing to install and giving me the error 
message: 
> > Failed to add PS file association
> 
> That's likely to be a consequence of not installing
> rather than an  indication of the root cause.  Does
it give any
> indication prior to that > of why it's not
installing?  

Not that I have seen so far. It looks okay to me (but
what do I know?) until it simply reports that it
cannot add the file association.  The log is at
http://ca.geocities.com/jrkrideau/LyX/GSinstallscript.pdf
if you want to take a look.

>(On a side note, have> you considered 
> sacrificing a small furry animal to the gods of 
computing before > installing things?  Works for me.)

Small furry animal be damned, I'm considering
something like a black bear.  I'm a bit too far south
for a moose.

John Kane, Kingston ON  Canada






__ 
Find your next car at http://autos.yahoo.ca

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?


John Kane wrote:


.  To verify your MinSYS
installation, you can open a DOS 
window and type 'sh' at the command prompt.  This
should start a shell 
and give you a prompt that looks like 'sh-2.04$'
(though possibly yours 
will have a higher version number).  If it does,
type 'exit' to get out 
of the shell.



Works fine



Assuming sh works, you might try running the
configure script in the DOS 
window.  Change to the directory C:\Program
Files\LyX\Resources\lyx, 
verify that a file named 'configure' is there, and
then execute 'sh 
configure'.  
That runs the configuration script. 



Does not work 
The file is there, all 43K of it, but “sh configure”

simply gives me an error message
'sh' is not recognized as an internal or external
command, operable program or batch file.


Ok, when you ran the first test (that worked correctly), were you in the 
msys\1.0\bin directory?  If so, then the combination of that working and 
the attempt to run the configure script not working would suggest that 
the MinSYS bin directory is not on your command path.  I thought, from 
your previous post, that it was, but just to double check, what do you 
get if you type 'path' at a command prompt?



As an update, I deleted, uninstalled, (and bleached
and scrubbed) everything again this morning and
reinstalled everything with LyX at c:\LyX  . I am
still getting the error message that the textclass
“XX” is not found but I now at least can see them in
the TeX Information list.


You're seeing them in LyX via View->TeX Information?  That's 
inconsistent with the textclass not found messages (assuming that 
textclass XX is in the TeX Information list).


I am unable to print. I did manage to export an ASCII
file!!.  


That's a positive step, but since ASCII export does not involve LaTeX, 
it's a small positive step.


I finally managed to download GSview and it is now
refusing to install and giving me the error message: 
Failed to add PS file association


That's likely to be a consequence of not installing rather than an 
indication of the root cause.  Does it give any indication prior to that 
of why it's not installing?  (On a side note, have you considered 
sacrificing a small furry animal to the gods of computing before 
installing things?  Works for me.)


Paul

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?


--- Stephen Harris <[EMAIL PROTECTED]> wrote:
> - Original Message - 
> From: "John Kane" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, November 10, 2005 2:05 PM
> Subject: Re: Installation Problem. All entries in
> Textclass.lst 
> are "false " so no output. Any suggestions?

---clip---

> If you have content in c:\msys\1.0\bin that should 
suffice.

It seems okay

> Did you remember to delete > Drag this to the
> recycle bin:  > C:\Documents and
Settings\username\Application Data\LyX

Yes

> I agree that Python23 should work (not part of >
problem).

Good I need that version.

> Probably a "large" install of Miktex should also 
suffice. So your helper programs appear to be in
order.

Thanks, that's reassuring.

> Try changing the default install directory to c:\lyx
> because paths with spaces, as in c:\program 
files\lyx
> isn't quite perfected, though it nearly always
works.

Tried this today. I am still getting the error
messages and I cannot print but I now can see the TEX
Infomation lists. One step.

> Remember to delete the old installation first. I am
> used to giving advice very thoroughly, so don't mind
it.

Much prefered to being to brief. 

> I'm including a screen capture of some of my .cls
> files so you can do a search and make sure you have
them.

As mentioned above, they have now appeared in the
lists.  The C:\LyX may have done it. 

> This is the searchable lyx user mailing list
> archive.>
http://www.mail-archive.com/lyx-users@lists.lyx.org/
> So a search for textclass.lst will return related
> problems.
> 
> Re: No classes is a thread about a similar problem
>
http://www.mail-archive.com/lyx-users@lists.lyx.org/msg41609.html

Yes if that is Banibrata 's thread I found it about an
hour after I posted. My searches were not finding much
before.  I need a better choice of keywords.

> From windows, you can use the cmd line (dos prompt)
> to get latex information with "kpsewhich
> article.cls" C:\texmf\..
> no quotation marks to obtain info about Latex
> installed files.

They are there. I counted 10 cls files in that
directory.

BTW I also am getting a GSview installation error
saying that the program Failed to add PS file
association: in the registry.

John Kane, Kingston ON  Canada






__ 
Find your next car at http://autos.yahoo.ca

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?

--- "Paul A. Rubin" <[EMAIL PROTECTED]> wrote:
> John Kane wrote:

> Hang on.  The ~2.8 MB file in Stephen's directory
> listing is probably 
> the installer, which you don't need once
> installation is done (and which 
> wouldn't necessarily be in that particular directory
> even if you did 
> keep it).  

Yes, Steven told me that.  

>.  To verify your MinSYS
> installation, you can open a DOS 
> window and type 'sh' at the command prompt.  This
> should start a shell 
> and give you a prompt that looks like 'sh-2.04$'
> (though possibly yours 
> will have a higher version number).  If it does,
> type 'exit' to get out 
> of the shell.

Works fine

> Assuming sh works, you might try running the
> configure script in the DOS 
> window.  Change to the directory C:\Program
> Files\LyX\Resources\lyx, 
> verify that a file named 'configure' is there, and
> then execute 'sh 
> configure'.  
>That runs the configuration script. 

Does not work 
The file is there, all 43K of it, but sh configure
simply gives me an error message
'sh' is not recognized as an internal or external
command, operable program or batch file.

 >If not, try 
> executing 'latex --version' at the command prompt
> and see if you get a 
> version message. 

Yes it looks fine. I got a compete version message.
> If not, there's a problem with
> your MiKTeX installation.
So hopefully this is okay. It takes an hour to
install. 

As an update, I deleted, uninstalled, (and bleached
and scrubbed) everything again this morning and
reinstalled everything with LyX at c:\LyX  . I am
still getting the error message that the textclass
XX is not found but I now at least can see them in
the TeX Information list.  All three categories are
displaying and I cross-checked as Steven suggest at
DOS level to confirm that the files (at least the cls
files) are in their directory.  

I am unable to print. I did manage to export an ASCII
file!!.  

I finally managed to download GSview and it is now
refusing to install and giving me the error message: 
Failed to add PS file association

Thanks for all the help. 

__ 
Find your next car at http://autos.yahoo.ca

Re: Installation Problem. All entries in Textclass.lst are "false " so no output. Any suggestions?