context program, mtxrun question?
![](https://secure.gravatar.com/avatar/1aaa8171e46f2c29d4441fa99a7fc634.jpg?s=120&d=mm&r=g)
Hi everyone,
aehmmm, looks nice, but
# let us see how the context wrapper looks like:
$ cat /usr/bin/context
#!/bin/sh
mtxrun --script context "$@"
# now see what mtxrun does ...
$ mtxrun --script context foobar
MtxRun | unknown script: context
$
Well not surprising ... there is NO context script anywhere in the
distribution!
Am I missing something?
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Norbert Preining wrote:
Well not surprising ... there is NO context script anywhere in the distribution!
Am I missing something?
The script is: scripts/context/lua/mtx-context.lua If mtxrun cannot find it, something went wrong running luatools --generate Best wishes, Taco
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Mon, May 19, 2008 at 9:03 AM, Taco Hoekwater wrote:
Norbert Preining wrote:
Well not surprising ... there is NO context script anywhere in the distribution!
Am I missing something?
The script is:
scripts/context/lua/mtx-context.lua
If mtxrun cannot find it, something went wrong running
luatools --generate
It seems to me that this is actually a yet unanswered FAQ: - the thread about AucTeX on ntg-context - Oliver asked me about how to run LuaTeX without having to set any environmental variables except for PATH adjustment; that would make the mac installer much easier to cope with - in most TeX distributions, one simply puts texmf.cnf somewhere above the binary (selfautoparent trickery), and then everything works out of the box - similar question raised by Vyatcheslav for Windows - I often have problems in my editor; if I launch it from terminal with proper environmental variables set, then it works OK, but if I want to launch it from menu, then it sometimes works and sometimes not (some weird interference with the existing distribution, in most cases it just doesn't find the cont-en.fmt and stops there already) I just wanted to raise the question as it appears in just every installation of TeX where one wants to use ConTeXt with LuaTeX. As long as one runs source setuptex in minimals, or source ~/.luatex in Thomas' instructions of hard-coded paths then LuaTeX runs OK, but if one would like to run LuaTeX without explicitly setting environmental variables (problematic within TeX editors), one soon runs into problems. Minimals contain texmf.cnf hidden somewhere in the tree. But even if I put in in the top folder, it doesn't help much. Hans also uses setuptex.tmf for reading settings with LuaTeX in some way, but again, it doesn't happen automatically. Jonathan Kew also told me that it should be enough to have a proper version of texmf.cnf in the top folder, and then setting PATH to include binaries should be enough. LuaTeX now works on standalone ConTeXt installation for more than a year, but it would be nice to make it work on Debian, TeX Live, MikTeX (that will soon provide it) ... as well. Any ideas if getting rid of dependency on environmental variables is doable? Mojca PS: ping hans@miktex
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Any ideas if getting rid of dependency on environmental variables is doable?
I agree it would be great if mtxrun could call/do setuptex on itself if needed.
At the moment for me it would be enough to know where exactly LuaTeX looks for configuration information (path & file name) and which files take precedence over others in the case of conflicts ... my current understanding is: 1. Environment variables 2. setuptex.tmf 3. texmf-context/web2c/context.cnf 4. texmf/web2c/texmf.cnf 5. ... As a second step, one would have to know what each of the settings in the above places is needed for. In particular, I would like to know which settings LuaTeX actually uses and which ones it ignores. But this can wait until the first question is figured out completely ;-) Best, Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Any ideas if getting rid of dependency on environmental variables is doable? I agree it would be great if mtxrun could call/do setuptex on itself if needed.
At the moment for me it would be enough to know where exactly LuaTeX looks for configuration information (path & file name) and which files take precedence over others in the case of conflicts ... my current understanding is:
1. Environment variables 2. setuptex.tmf
no, this one is only used when you run mtxrun --tree=.... i use this methos in web driven workflows where we can have multiple trees alongside (linux servers) and i never bother to setup my shell for that; i just call mtxrun then
3. texmf-context/web2c/context.cnf
we ship context.cnfas an example of what is needed (it's the one on my machine)
4. texmf/web2c/texmf.cnf
that one indeed unless it's in a usual place
5. ...
$TEXMF $TEXMFCACHE (since there is no agreement over where it lives) so, only two variables
As a second step, one would have to know what each of the settings in the above places is needed for. In particular, I would like to know which settings LuaTeX actually uses and which ones it ignores. But this can wait until the first question is figured out completely ;-)
$TEXMF is needed in order to locate the configuration file (currently still a CNF file but we may as well get rid of it since we use less and less info from it; if we would organize the minimals differently i.e. more flat that tds we can do without a configuration, especially fonts are an issue (why no tex/fonts/data/vendor/collection) $TEXMFCACHE is needed because distributers want control over the place where those files go; there is some default setup but ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
At the moment for me it would be enough to know where exactly LuaTeX looks for configuration information (path & file name) and which files take precedence over others in the case of conflicts ... my current understanding is: 1. Environment variables 2. setuptex.tmf
no, this one is only used when you run
mtxrun --tree=....
i use this methos in web driven workflows where we can have multiple trees alongside (linux servers) and i never bother to setup my shell for that; i just call mtxrun then
OK, just to confirm, the file setuptex.tmf at the top level of a set of tex trees is *only* ever evaluated by mtxrun. In turn, if I never intend to run mtxrun --tree=... I can safely delete this file. (A quick grep shows that the file setuptex.tmf also seems to be used by runtools.rb and texmfstart.rb for the same purpose but since these scripts are obsolete for LuaTeX this can be ignored).
3. texmf-context/web2c/context.cnf
we ship context.cnfas an example of what is needed (it's the one on my machine)
In other words, deleting context.cnf from texmf-context/web2c/ makes no difference whatsoever for LuaTeX?
4. texmf/web2c/texmf.cnf
that one indeed unless it's in a usual place
OK, again just to be sure: the file texmf/web2c/texmf.cnf (exactly in this location) is the central configuration file for LuaTeX (and actually the only one needed after deleting the ones mentioned above). However, without the environment variable $TEXMF LuaTeX won't be able to find it and will give up. Now if $TEXMF is set LuaTeX will search all the trees specified there in the given order until it finds the file at anytexmf/web2c/ texmf.cnf. What if the file texmf.cnf is in a different location within $TEXMF? Will LuaTeX still find it?
As a second step, one would have to know what each of the settings in the above places is needed for. In particular, I would like to know which settings LuaTeX actually uses and which ones it ignores. But this can wait until the first question is figured out completely ;-)
$TEXMF is needed in order to locate the configuration file
Why does LuaTeX need an environment variable for that? Both pdftex and xetex in the minimal distribution run flawlessly without any variable set. Besides TeXLive 2007 doesn't need that either. Why can't there be a default location where LuaTeX looks for its configuration file (be it texmf.cnf or something else)?
(currently still a CNF file but we may as well get rid of it since we use less and less info from it;
This is what I actually wanted to know in the second step ... which info from texmf.cnf is used by LuaTeX and what is ignored? What aspects of LuaTeX are configured by each single line? Furthermore, which info is mandatory and what is optional?
if we would organize the minimals differently i.e. more flat that tds we can do without a configuration, especially fonts are an issue (why no tex/fonts/data/vendor/collection)
I don't understand.
$TEXMFCACHE is needed because distributers want control over the place where those files go; there is some default setup but ...
Yes, unless $TEXMFCACHE is set, LuaTeX uses $HOME/luatex-cache. Can the cache path also be set in the file texmf.cnf? Best, Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi Oliver, Hans and I are extending context in this area right now, so any current answer will likely be outdated before much longer. So, a little bit of extra patience is required still. All the best, Taco
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Hans and I are extending context in this area right now, so any current answer will likely be outdated before much longer. So, a little bit of extra patience is required still.
I see. It's just that literally everything about ConTeXt is changing on a daily basis and almost every current answer about just any topic seems to be outdated within a fortnight. However, if you want user-friendly ConTeXt distributions to hit the main stage at some point you'll have to start somewhere. Refusing to explain the details because they're going to change anyway probably won't be the best idea ... On the other hand, if you want ConTeXt distributions to always remain almost exact replicas of Hans' machine (like the current minimals are), fine. But don't expect them to be widely usable. The average user doesn't have the knowhow required to happily juggle with dozens of configurations sitting side by side. Sorry for putting this bluntly but I feel something had to be said about this issue. I guess it won't do you any harm if you shared your plans about LuaTeX's configuration mechanism with us package developers ... thus we wouldn't have to reverse engineer every tiny bit. Oliver
![](https://secure.gravatar.com/avatar/0ed499139c984ed1c5c6312376a707e5.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
On the other hand, if you want ConTeXt distributions to always remain almost exact replicas of Hans' machine (like the current minimals are), fine. But don't expect them to be widely usable. The average user doesn't have the knowhow required to happily juggle with dozens of configurations sitting side by side.
In fairness the average user shouldn't be using any luatex/Mk IV stuff yet - it is still in alpha/beta. I have whole production environments built around ConTeXt minimals and they are extremely usable across multiple architectures, mainly because they are still based on Mk II. Mk IV is not (meant to be) production level yet. Just my humble opinion... :-) Duncan
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
On the other hand, if you want ConTeXt distributions to always remain almost exact replicas of Hans' machine (like the current minimals are), fine. But don't expect them to be widely usable. The average user doesn't have the knowhow required to happily juggle with dozens of configurations sitting side by side.
In fairness the average user shouldn't be using any luatex/Mk IV stuff yet - it is still in alpha/beta. I have whole production environments built around ConTeXt minimals and they are extremely usable across multiple architectures, mainly because they are still based on Mk II. Mk IV is not (meant to be) production level yet.
Just my humble opinion... :-)
Fair enough ... if you know bits and pieces about TeX and aren't afraid of the shell you'll certainly have the MKII minimals up and running at some point ;-) However, think of someone who has never heard of ConTeXt before but has been persuaded by a friend or colleague to give it a try. Perhaps they've been given a template document for a thesis to start from. If this person has a Mac they'll probably want to download some disk image, have ConTeXt deployed on their machine by the Apple installer program, fire up TeXShop and start writing their thesis with ConTeXt right away. This is what I'd consider the average user. With the current minimals this is impossible ... Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
However, think of someone who has never heard of ConTeXt before but has been persuaded by a friend or colleague to give it a try. Perhaps they've been given a template document for a thesis to start from. If this person has a Mac they'll probably want to download some disk image, have ConTeXt deployed on their machine by the Apple installer program, fire up TeXShop and start writing their thesis with ConTeXt right away. This is what I'd consider the average user. With the current minimals this is impossible ...
hm, i really had it up and running on the mac pretty fast in texshop but since my mac is permantly broken i cannot test it right now ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
However, think of someone who has never heard of ConTeXt before but has been persuaded by a friend or colleague to give it a try. Perhaps they've been given a template document for a thesis to start from. If this person has a Mac they'll probably want to download some disk image, have ConTeXt deployed on their machine by the Apple installer program, fire up TeXShop and start writing their thesis with ConTeXt right away. This is what I'd consider the average user. With the current minimals this is impossible ...
hm, i really had it up and running on the mac pretty fast in texshop but since my mac is permantly broken i cannot test it right now
Well, you're an IT pro ... that makes all the difference ;-) Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
However, think of someone who has never heard of ConTeXt before but has been persuaded by a friend or colleague to give it a try. Perhaps they've been given a template document for a thesis to start from. If this person has a Mac they'll probably want to download some disk image, have ConTeXt deployed on their machine by the Apple installer program, fire up TeXShop and start writing their thesis with ConTeXt right away. This is what I'd consider the average user. With the current minimals this is impossible ...
hm, i really had it up and running on the mac pretty fast in texshop but since my mac is permantly broken i cannot test it right now
Well, you're an IT pro ... that makes all the difference ;-)
i'm a complete mac-dummy so for me it was a matter of: - unzip a minimal - make sure that texshop intializes that tree btw, there will me a cross platform 'texshop' variant (tug funded project) and at some point we need to get context support in there Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Hans and I are extending context in this area right now, so any current answer will likely be outdated before much longer. So, a little bit of extra patience is required still.
I see. It's just that literally everything about ConTeXt is changing on a daily basis and almost every current answer about just any topic seems to be outdated within a fortnight.
Well, what else do you expect from code that is in active development? Sorry, but this rant does not make a lot of sense. Context MKIV and Luatex are *not* production systems, and we do not claim they are. If you are unhappy with code that is in still moving fast, stick to MKII. MKII has been pretty stable for years now. I wrote that message yesterday to let you know that we are actively working to make the situation better. It quite a cold shower to get flamed for doing exactly that. Taco
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Taco Hoekwater wrote:
I wrote that message yesterday to let you know that we are actively working to make the situation better. It quite a cold shower to get flamed for doing exactly that.
also, keep in mind that taco and i are working nearly full time on it and asking for documentation of changing code would force us to skip sleeping Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Hello Taco,
I see. It's just that literally everything about ConTeXt is changing on a daily basis and almost every current answer about just any topic seems to be outdated within a fortnight.
Well, what else do you expect from code that is in active development?
Sorry, but this rant does not make a lot of sense. Context MKIV and Luatex are *not* production systems, and we do not claim they are. If you are unhappy with code that is in still moving fast, stick to MKII. MKII has been pretty stable for years now.
I'm perfectly aware of the fact that MKIV isn't ready for prime time yet. Still I remember that from one MKII release to the next bugs kept creeping into the code that suddenly broke everything. Wrecked font handling in combination with XeTeX around the beginning of last year comes to my mind as just one of the topics people were having trouble with. From personal experience in the middle of a project at that time I also remember a few other problems with MKII ... besides I was having the impression that for each new MKII release that didn't solve a specific bug you'd have to adapt the original workaround. So compared to MKIV I certainly agree with you that MKII is pretty stable, but in comparison with other projects probably not stable enough for many users. In my opinion this is the very reason why that discussion about quality assurance and regression testing came up at all during the conference in Epen last March. And this is also why I made the comment about the ever changing ConTeXt. Additionally, from the point of view of a package developer I keep having the feeling that more often than not the reasons for certain changes are left in the dark rather than explained. For example, my understanding is that many Perl scripts have been superseded by Ruby scripts over time, still they're shipped with current MKII minimals. Unfortunately there's no documentation about whether they could actually be deleted or whether there are still some (rare) tasks they're needed for. And then they seem to access dozens of environment variables and configuration files so you have no clue about whether those are needed or not. You just have to know. Which I don't. When I was trying to put together a Mac installer for MKII a couple of months ago I kept hearing the same definitely maybes about this configuration data issue as the ones I'm facing now -- only at that time the game wasn't called LuaTeX. Not having had the time to reverse engineer everything I gave up then. Recently I had the chance to work on the Mac installer again and after some progress I got stuck at the very same vital point called configuration information and how it's accessed.
I wrote that message yesterday to let you know that we are actively working to make the situation better. It quite a cold shower to get flamed for doing exactly that.
Taco
Admittedly, I phrased my comment rather provocatively ... if you feel offended personally I apologize. I appreciate very much what both you and Hans do. Otherwise I wouldn't use ConTeXt at all and even more certainly wouldn't be concerned with a Mac package for it. Still I find the current situation rather frustrating ... in fairness I think this is also quite understandable from the above. Anyway, for the moment I'll stay put and wait for the configuration mechanism to stabilize. Once that has happened I'd be delighted to get to know the details about how it works ... then the Mac installer could also enter the stage finally. Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Still I remember that from one MKII release to the next bugs kept creeping into the code that suddenly broke everything. Wrecked font handling in combination with XeTeX around the beginning of last year comes to my mind as just one of the topics people were having trouble
xetex is a moveing target too, and i think that in that respect latex/xetex users also have to update in sync with binaries; by now the xetex interface becomes more stable but it's still version < 1
with. From personal experience in the middle of a project at that time I also remember a few other problems with MKII ... besides I was having the impression that for each new MKII release that didn't solve a specific bug you'd have to adapt the original workaround.
depends, many parts are pretty stable but if you let a project depend on new features ...
understanding is that many Perl scripts have been superseded by Ruby scripts over time, still they're shipped with current MKII minimals.
i'm not ure what you mean here; we only keep perl scripts around for stuff that is not yet redone in ruby or because soem workflows may depend on it; if a user uses "texmfstart somescript" he or she will now notice if a perl or ruby script is used; therefore we could make a transition
Unfortunately there's no documentation about whether they could actually be deleted or whether there are still some (rare) tasks they're needed
depends on what kind of workflows one has; also some scripts are shipped that probably are used as pragma but since we use the same zips for updating i keep 'm there
for. And then they seem to access dozens of environment variables and configuration files so you have no clue about whether those are needed or not. You just have to know. Which I don't.
it all depends on your local system ... in the minimals 'setuptex' just plays safe ... it sets up all variables that can interfere with an existing installation
When I was trying to put together a Mac installer for MKII a couple of months ago I kept hearing the same definitely maybes about this configuration data issue as the ones I'm facing now -- only at that time the game wasn't called LuaTeX. Not having had the time to reverse engineer everything I gave up then.
hm, platform issues .. each platform has its own demands too and we can only adapt the minimals have been around for ages and not much changed for a long time; a few month ago we started thinking of and working on a garden based one and in the process of making engine specific variants (even more minimals) quite some experimenting is needed; these are not things that can be done in a few hours or weeks or months, especially not if you consider that tex distributions (and their contents, like fonts) change every now and then too
Recently I had the chance to work on the Mac installer again and after some progress I got stuck at the very same vital point called configuration information and how it's accessed.
i wonder what configuration info you refer too; in a minimals setup there is only 'setuptex' and optionally one may want to adapt the cont-sys.tex file
I wrote that message yesterday to let you know that we are actively working to make the situation better. It quite a cold shower to get flamed for doing exactly that.
Taco
Admittedly, I phrased my comment rather provocatively ... if you feel offended personally I apologize. I appreciate very much what both you and Hans do. Otherwise I wouldn't use ConTeXt at all and even more certainly wouldn't be concerned with a Mac package for it.
Still I find the current situation rather frustrating ... in fairness I think this is also quite understandable from the above. Anyway, for the moment I'll stay put and wait for the configuration mechanism to stabilize. Once that has happened I'd be delighted to get to know the details about how it works ... then the Mac installer could also enter the stage finally.
as taco mentioned ... mkiv is for the brave ... we will cook up something that makes it usable for tex live but even then ... it will take a while Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
From personal experience in the middle of a project at that time I also remember a few other problems with MKII ... besides I was having the impression that for each new MKII release that didn't solve a specific bug you'd have to adapt the original workaround.
depends, many parts are pretty stable but if you let a project depend on new features ...
Well, my feeling is some buggy parts weren't all that new at that time ...
understanding is that many Perl scripts have been superseded by Ruby scripts over time, still they're shipped with current MKII minimals.
i'm not ure what you mean here; we only keep perl scripts around for stuff that is not yet redone in ruby or because soem workflows may depend on it;
What I mean is that there is stuff lurking around in the minimals which is obsolete apart from rare (and presumably advanced) usage scenarios. However, this stuff makes trying to figure out the interdepencies of configuration files and variables quite a daunting task to say the least. For a suggestion on how to remedy this situation see my lines below.
Unfortunately there's no documentation about whether they could actually be deleted or whether there are still some (rare) tasks they're needed
depends on what kind of workflows one has; also some scripts are shipped that probably are used as pragma but since we use the same zips for updating i keep 'm there
Don't get me wrong but this is exactly the vague kind of answers I was referring to in my initial posting. As far as workflows are concerned my opinion is that keeping things *simple* should be the primary goal for any ConTeXt minimal distribution. One should agree on the simplest ConTeXt workflow possible and then design the minimals primarily with that idea in mind rather than trying to support each and every workflow under the sun right *out of the box*. The most common scenario will most probably be the average desktop user wanting to typeset a document interactively. That said, one could collect the legacy stuff you mentioned into a separate package for a start and clearly mark it as such. I think this should be feasible on all platforms ConTeXt runs on. The benefits of this approach abound: less scripts, less interdependencies to worry about, less environment variables, sleeker minimal distributions. Note that neither power nor flexibility would suffer: experienced TeX users will be able to tailor their minimals installation to meet the needs of an enterprise workflow anyway. If you need legacy stuff for old projects you extend the minimals with the appropriate component. If you need multiple ConTeXt trees within a web based workflow you put in those setuptex.tmf files and anything else that may be required. I hope this will clarify my point of view.
for. And then they seem to access dozens of environment variables and configuration files so you have no clue about whether those are needed or not. You just have to know. Which I don't.
it all depends on your local system ... in the minimals 'setuptex' just plays safe ... it sets up all variables that can interfere with an existing installation
If course, it depends on my local system. However, as a rule of thumb every installation of TeX (if there are several ones) should be responsible for not leaving behind any mess when it's not in use. Just my humble opinion how playing safe could be understood. Also, this is precisely what happens on a Mac when you have several versions of TeX Live, Fink-teTeX, MacPorts-teTeX etc. happily sitting side by side with zero effort on the user part ... Now this is my one and only motivation for getting rid of the shell script "setuptex" and the need for all those environment variables. There's really nothing more to all my questions about configuration files ...
Recently I had the chance to work on the Mac installer again and after some progress I got stuck at the very same vital point called configuration information and how it's accessed.
i wonder what configuration info you refer too; in a minimals setup there is only 'setuptex' and optionally one may want to adapt the cont-sys.tex file
I was referring to setuptex.sh setuptex.tmf context.cnf texmf.cnf environment variables and how the information contained therein is accessed (if at all) by the different engines and scripts.
Still I find the current situation rather frustrating ... in fairness I think this is also quite understandable from the above. Anyway, for the moment I'll stay put and wait for the configuration mechanism to stabilize. Once that has happened I'd be delighted to get to know the details about how it works ... then the Mac installer could also enter the stage finally.
as taco mentioned ... mkiv is for the brave ... we will cook up something that makes it usable for tex live but even then ... it will take a while
Honestly, to my ears this sounds like a contradiction. If you consider MKIV for the brave then why include it in TeX Live at all? Once I read that the ConTeXt shipping with TeX Live should be regarded as the official stable release ... Oliver
![](https://secure.gravatar.com/avatar/0ed499139c984ed1c5c6312376a707e5.jpg?s=120&d=mm&r=g)
As far as workflows are concerned my opinion is that keeping things *simple* should be the primary goal for any ConTeXt minimal distribution. I think you may have misunderstood the purpose of the minimals. "Minimal" here generally refers to effort - both on Hans' side and on
Oliver Buerschaper wrote: the user's side - rather than any notion of these distributions being stripped down. There has been some discussion on the main list of the stripped down distribution type that I think you're looking for, but it's important to know that the minimals are *not* it. The minimals are designed as an "unzip and go" *complete* package - "everything with minimal effort", not "the minimum you need to get started".
Now this is my one and only motivation for getting rid of the shell script "setuptex" and the need for all those environment variables. There's really nothing more to all my questions about configuration files ...
This is also illuminating. The concept of the setuptex script (as I understand it) is precisely to allow the minimals to operate completely independently of any other installed TeX systems. The point is that you only run the setuptex script in the shell in which you want to run ConTeXt. These environment variables aren't meant to be set globally (again, AFAIK), they are meant to be set for the session. To me this is what makes the minimals highly portable and easy to integrate into cross-platform scripts and applications. Your issues appear to me to be rather specific to your own environment, which perhaps does not allow you to run in this way.
One should agree on the simplest ConTeXt workflow possible and then design the minimals primarily with that idea in mind rather than trying to support each and every workflow under the sun right *out of the box*. The most common scenario will most probably be the average desktop user wanting to typeset a document interactively.
The simplest workflow possible is quite a different proposition, and should not be being addressed by the minimals. And the "average desktop user" is extremely difficult to define for ConTeXt - I suspect they don't use a Mac, for a start. :-) Duncan
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Duncan Hothersall wrote:
only run the setuptex script in the shell in which you want to run ConTeXt. These environment variables aren't meant to be set globally (again, AFAIK), they are meant to be set for the session. To me this is what makes the minimals highly portable and easy to integrate into cross-platform scripts and applications.
indeed, and for users who have multiple projects the minimals give them isolated installations; this is why there are texmf-fonts (for commercial fonts) and texmf-project paths as well: you install a minimal, and copy unique stuff to texmf-fonts and texmf-projects Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
I think you may have misunderstood the purpose of the minimals. "Minimal" here generally refers to effort - both on Hans' side and on the user's side - rather than any notion of these distributions being stripped down. There has been some discussion on the main list of the stripped down distribution type that I think you're looking for, but it's important to know that the minimals are *not* it. The minimals are designed as an "unzip and go" *complete* package - "everything with minimal effort", not "the minimum you need to get started".
Indeed, I followed the thread about the ultraminimals on the other list. However, I wasn't talking about stripping down Hans' standalone distribution to the bare minimum ... this would certainly need "maximal" rather than "minimal" effort on Hans' and Taco's side. What I was striving for is merely stripping down the complexity of the configuration mechanism for now. Most probably this would reduce a package developer's effort from "maximal" to "intermediate". Modularizing the whole distribution into small, cleanly separated components is quite another project. Without doubt ConTeXt would benefit a great deal from that but this is *not* the issue I was addressing in my post.
This is also illuminating. The concept of the setuptex script (as I understand it) is precisely to allow the minimals to operate completely independently of any other installed TeX systems. The point is that you only run the setuptex script in the shell in which you want to run ConTeXt. These environment variables aren't meant to be set globally (again, AFAIK), they are meant to be set for the session.
There I think you've exactly pinned down the problem. Each application wanting to run ConTeXt must call it from a wrapper script which sets these environment variables for the local shell. Keep in mind though that (at least on the Mac) this wrapper script is only needed for the minimals ... and certainly not for the ConTeXt from TeX Live, for example. If you use TeXShop as your frontend you'd then have to have different ConTeXt typesetting commands for each and every TeX distribution on your machine. Not exactly user-friendly ... Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Honestly, to my ears this sounds like a contradiction. If you consider MKIV for the brave then why include it in TeX Live at all? Once I read that the ConTeXt shipping with TeX Live should be regarded as the official stable release ...
We have not added mkiv to texlive. If it is included now, then that is thanks to Norbert's packaging. Best wishes, Taco
![](https://secure.gravatar.com/avatar/1aaa8171e46f2c29d4441fa99a7fc634.jpg?s=120&d=mm&r=g)
On Mi, 21 Mai 2008, Taco Hoekwater wrote:
that the ConTeXt shipping with TeX Live should be regarded as the official stable release ...
We have not added mkiv to texlive. If it is included now, then that is thanks to Norbert's packaging.
No I didn't add anything to the TeX Live repository, that I leave to
Taco/Hans/whoever. I would say it is up to them to ship what they
consider fine.
I am trying to package the latest context for Debian.
But AFAIS, the whole context could in fact be omitted. As far as I see
*everyone* using context also uses his home-grown installation etc ;-)
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Fri, May 23, 2008 at 7:45 PM, Norbert Preining wrote:
But AFAIS, the whole context could in fact be omitted. As far as I see *everyone* using context also uses his home-grown installation etc ;-)
- ConTeXt on MikTeX is completely/absolutely broken - TeX Live is outdated - ConTeX/XeTeX on gwTeX is broken - LuaTeX doesn't work at all, anywhere (except for the Debian) What else (apart from W32TeX) remains out there? Let's see how the new packaging in TeX Live is going to work ... :) :) :) Mojca
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
On Fri, May 23, 2008 at 7:45 PM, Norbert Preining wrote:
But AFAIS, the whole context could in fact be omitted. As far as I see *everyone* using context also uses his home-grown installation etc ;-)
- ConTeXt on MikTeX is completely/absolutely broken - TeX Live is outdated
sure, but tex live always had a relative stable version of context and i'd like to keep that property
- ConTeX/XeTeX on gwTeX is broken
hm
- LuaTeX doesn't work at all, anywhere (except for the Debian)
i'm glad that norbert packages luatex/mkiv because it gives us a reference outside out own machines
What else (apart from W32TeX) remains out there?
commercial tex's
Let's see how the new packaging in TeX Live is going to work ... :) :) :)
don't worry, mkii will be in there anyway and i see no reason not to have mkiv in there too Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Norbert Preining wrote:
On Mi, 21 Mai 2008, Taco Hoekwater wrote:
that the ConTeXt shipping with TeX Live should be regarded as the official stable release ... We have not added mkiv to texlive. If it is included now, then that is thanks to Norbert's packaging.
No I didn't add anything to the TeX Live repository, that I leave to Taco/Hans/whoever. I would say it is up to them to ship what they consider fine.
I am trying to package the latest context for Debian.
But AFAIS, the whole context could in fact be omitted. As far as I see *everyone* using context also uses his home-grown installation etc ;-)
not true -) the so called minimals are based on my personal subset that i use in project; one can consider them a kind if reference subset and they can be used of course; however, it leave out all the other tex stuff: no other macro packages, less binaries, less fonts, etc Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
I was referring to
setuptex.sh
All scripts starting with setuptex have the same functionality: they set up all the needed environment variables I have seen the following, that only differ per platform: setuptex,setuptex.sh % unix bash shell setuptex.csh % unix csh shell setuptex.bat,setuptex.cmd % windows shell
setuptex.tmf
This one can be used by texmfstart if you run it with texmfstart --tree= and is only for advanced use.
context.cnf
this file is not used, ever.
texmf.cnf
This is read by mkii (in the normal way, via kathsea, as well as via texmfstart's file searching routines) and in mkiv by luatools when --generate is given on the command line (the rest of mkiv uses preprocessed data from the cache). As of this morning, we also have
texmfcnf.lua
that is always read by all of mkiv.
environment variables
These are set up by setuptex, but I assume you want to know what each does. Will you still care if they go away anyway? digging this information up though all the nooks and crannies of mkii is quite a bit of work.
and how the information contained therein is accessed (if at all) by the different engines and scripts.
More or less the same question again. How much of this do you really need to know? Because generally speaking, there are more sensible things to do than to document all thoses lines of code in a separate implementation manual. If you are curious about a few variables, can you please post which ones? Best wishes, Taco
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Well, my feeling is some buggy parts weren't all that new at that time ...
some stuff is 'experimental' and therefore 'buggy' by definition ... if only because there is no one and perfect solution in traditional tex ... which is why we started the luatex project in the transition to mkiv it means that parts of context have to be split in kii and mkiv code (a rather tricky thing btw) so if you have a workflow wher eyou cannot update regularly, you should stick to the museum versions that taco mentioned (which also means, stick to pdftex for a while) we expect to need another two years to get luatex and mkiv in a state that most interfaces are stable
What I mean is that there is stuff lurking around in the minimals which is obsolete apart from rare (and presumably advanced) usage scenarios.
probably, so best is to ignore anything that does not ring a bell; i made the minimal because i needed them in projects and then found out that users could benefit from them (after all, there are the regular distributions (norbert, akira and gerben took care of that) for those who want things out of a box)
However, this stuff makes trying to figure out the interdepencies of configuration files and variables quite a daunting task to say the least. For a suggestion on how to remedy this situation see my lines below.
well, in the minimals there's only TEXMF (and TEXMFCNF) and TEXMFCACHE and all the rest is to prevent interference; all these are discussed in the TDS/KPSE documentation
Unfortunately there's no documentation about whether they could actually be deleted or whether there are still some (rare) tasks they're needed
depends on what kind of workflows one has; also some scripts are shipped that probably are used as pragma but since we use the same zips for updating i keep 'm there
Don't get me wrong but this is exactly the vague kind of answers I was referring to in my initial posting.
well, users only need texmfstart and texexec (unless they want to do tricky things like generating font metrics or manipulating graphics; this is described in docs on the web but not for average users)
As far as workflows are concerned my opinion is that keeping things *simple* should be the primary goal for any ConTeXt minimal distribution. One should agree on the simplest ConTeXt workflow possible
as duncan said .. minimal is not the same as small, it's just a subset
and then design the minimals primarily with that idea in mind rather than trying to support each and every workflow under the sun right *out of the box*. The most common scenario will most probably be the average desktop user wanting to typeset a document interactively.
that would mean that i'd have to cook up additional stuff for myself and there is no time for that (unless someone pays me for it); if i cannot use the minimals myself, i cannot spend too much time on it
That said, one could collect the legacy stuff you mentioned into a separate package for a start and clearly mark it as such. I think this should be feasible on all platforms ConTeXt runs on. The benefits of this approach abound: less scripts, less interdependencies to worry about, less environment variables, sleeker minimal distributions.
it would not make a difference, the only legacy stuff is some ruby scripts and some styles; it has nothing to do with environment variables
Note that neither power nor flexibility would suffer: experienced TeX users will be able to tailor their minimals installation to meet the needs of an enterprise workflow anyway. If you need legacy stuff for old projects you extend the minimals with the appropriate component. If you need multiple ConTeXt trees within a web based workflow you put in those setuptex.tmf files and anything else that may be required.
well, as said, having yet another subset would make my live misserable bit anyone is free to make yet another minimal-minimal; maybe someone only wants latin modern, etc etc
I hope this will clarify my point of view.
sure, but i just have no time for more variants
for. And then they seem to access dozens of environment variables and configuration files so you have no clue about whether those are needed or not. You just have to know. Which I don't.
it all depends on your local system ... in the minimals 'setuptex' just plays safe ... it sets up all variables that can interfere with an existing installation
If course, it depends on my local system. However, as a rule of thumb every installation of TeX (if there are several ones) should be responsible for not leaving behind any mess when it's not in use. Just my humble opinion how playing safe could be understood. Also, this is precisely what happens on a Mac when you have several versions of TeX Live, Fink-teTeX, MacPorts-teTeX etc. happily sitting side by side with zero effort on the user part ...
you're over optimistic ... i just logged in on one of our servers ... controller-1:~ # set | grep -i TEX TEXINPUTS=:/root/.TeX:/usr/share/doc/.TeX:/usr/doc/.TeX tex | latex | pdflatex) e='!*.+(tex|TEX|texi|latex)' see what i mean? and i really didn't install anything tex on that machine (older machines have even more)
Now this is my one and only motivation for getting rid of the shell script "setuptex" and the need for all those environment variables. There's really nothing more to all my questions about configuration files ...
what is the problem with running just one script to set up the system? after all, if you don't call setuptex, you still need to set up the path (and i never set up the path because i can have multiple tex trees)
Recently I had the chance to work on the Mac installer again and after some progress I got stuck at the very same vital point called configuration information and how it's accessed.
i wonder what configuration info you refer too; in a minimals setup there is only 'setuptex' and optionally one may want to adapt the cont-sys.tex file
I was referring to
setuptex.sh setuptex.tmf
all the same (there's also setuptex.bat) and the tmf file can be used when you run from an editor (in which case the --tree=... flag will look for that file)
context.cnf
an example fo what i use here; handy for users who want to know the mem values
texmf.cnf
always needed
environment variables
which ones? i never set any, since setuptex does it for me
and how the information contained therein is accessed (if at all) by the different engines and scripts.
ah ... that's another story ... for that you need to consult the tds documentation and the kpse/web2c documentation
Still I find the current situation rather frustrating ... in fairness I think this is also quite understandable from the above. Anyway, for the moment I'll stay put and wait for the configuration mechanism to stabilize. Once that has happened I'd be delighted to get to know the details about how it works ... then the Mac installer could also enter the stage finally.
as taco mentioned ... mkiv is for the brave ... we will cook up something that makes it usable for tex live but even then ... it will take a while
Honestly, to my ears this sounds like a contradiction. If you consider MKIV for the brave then why include it in TeX Live at all? Once I read that the ConTeXt shipping with TeX Live should be regarded as the official stable release ...
because there are brave tex live users and because luatex itself will be on tex live (used as scripting engine so be prepared for another kick out ruby/perl/bash round); we also need to 'proof that it's possible' -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi Oliver, I was a bit more ticked off yesterday than I really had right to, in retrospect. The big problem is that tex installations become more unpredictable the further they are away from Hans' private machine. Even my own machine(s) sometimes behaves differently from his, and mine in fact are extremely closeby. That means we already spend a lot of effort in packaging, and it is annoying when whatever we do is still not good enough. Anyway, here's some thoughts and explanations Oliver Buerschaper wrote:
Still I remember that from one MKII release to the next bugs kept creeping into the code that suddenly broke everything.
Yes, and even if we try really hard to not insert bugs, it simply cannot be helped. There is no regression test suite at the moment, and nobody seems motivated to create one. Hans and I certainly do not have time to set such a thing up. But even if there was a test suite: it would likely run for days on end, so we could probably not afford to run it before each release in any case. We've been working with separate "production", "beta" and "alpha" releases for a while, but that did not work either. The "alpha" release usually went untested outside of the Hans-me circle, so there was no point in having it. In fact "beta" releases had the same problem until Hans may ctxtools --update default to fetching the beta (if there was one newer than production). To make matters worse, then "beta" was (maybe still is) picked up automatically by Gerben Wierda's i-installer. So even our "test" releases suddenly appeared in users' production settings. The whole situation is why the museum was created: at least you will always be able to revert back to an older context release if something suddenly becomes broken in a production project.
Additionally, from the point of view of a package developer I keep having the feeling that more often than not the reasons for certain changes are left in the dark rather than explained. For example, my understanding is that many Perl scripts have been superseded by Ruby scripts over time, still they're shipped with current MKII minimals.
The perl scripts you mean? I don't know about that. I know there are a few that are not (yet) converted to ruby, if there really duplicates still in minimals, then the perl ones should be removed. Mojca, can you give some comments on this?
And then they seem to access dozens of environment variables and configuration files so you have no clue about whether those are needed or not. You just have to know. Which I don't.
Over the past two days, we have been working on getting rid of all of those environment variables. What we have so far only applies to mkiv, but doing a similar thing to texmfstart (and thereby all of mkii) should be relatively simple. First. let's talk about mkiv. Later today (maybe already by the time you read this) there will be a new beta release in which mkiv (to be exact: luatools.lua, mtxrun.lua and the format-including luat-inp.lua) should be able to do without any environment variables, assuming the following condition is met: luatex and texlua(c) have to be installed in a TDS compliant directory that is inside the search PATH. The lua code uses an internal form of autoparent discovery to find the directory where the texmf.cnf resides. (Btw, This is another one of those things where it worked for Hans in an hour, then it took two full days to get it to work for me. It is likely that another day or two are needed to make it work on texlive-based systems, and Miktex may take even more time. Well, it works for me now, so now it is time for other web2c-style people to have a try. We can worry about Miktex and /usr/bin/ installations later, ok?) Now for the details: For luatools --generate, the key task is to find the configuration file directory (or directories), and this is handled by input.identify_cnf in luat-inp.lua. First, if TEXMFCNF is set, It is traversed and all found texmf.cnf are read in. This is normal behavior for web2c based systems, and is not changed from last week's logic. But if TEXMFCNF is not set, MkIV will attempt to find a single default configuration file, based on the location of the luatex or texlua binary (and that should be something like /opt/tex/texmf-linux/bin). It actually traverses PATH to find the executable with the name that was in argv[0]. I suspect that absolute path names will also work, but that is untested (and nonstandard). So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order: [/opt/tex/texmf]/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c Searching stops as soon as a texmf.cnf is found: you can not have multiple texmf.cnfs if TEXMFCNF is not set, and the directory tests are not all that elaborate. You cannot setup a chained TEXMFCNF inside of texmf.cnf, either. Please note this implementation logic is not set in stone yet. We preferred to start as simple as possible, but extensions may be needed. (currently we have a "works for me" system). Keep in mind that if your installation is really outlandish, you can just set TEXMFCNF in the environment explicitly. And that is nearly all there is to explain. I have MKIV running now with nothing changed in my system except an addition to PATH. ------ However, this all applies to luatools.lua in particular, because luatools parses the texmf.cnf and stores the preprocessed version inside the luatex-cache tree. But there is a bit of extra functionality we have had to add: you may not like the luatex-cache to appear in your $HOME. It is not possible to set TEXMFCACHE in texmf.cnf because of a chicken-and-egg situation, so we came up with something else. Alongside each texmf.cnf (more exact: in each directory where a texmf.cnf can exist), there can be a lua file with name texmfcnf.lua. All such files will be read before any of the texmf.cnfs, and so they can be used to overrule texmf.cnf values, TEXMFCACHE in particular. The lua script has to return a table. Mine (I have only one) looks like this: config = {} config.TEXMFCACHE = "/tmp" return config ------- Comments and testing are welcome, of course. Best wishes, Taco
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Taco Hoekwater wrote:
Please note this implementation logic is not set in stone yet. We preferred to start as simple as possible, but extensions may be needed. (currently we have a "works for me" system). Keep in mind that if your installation is really outlandish, you can just set TEXMFCNF in the environment explicitly.
an additional note: it is important to keep in mind that when you don't set TEXMFCNF and TEXMF, ther eis a potential clash with existing tex installations; the main reason for having setuptex in the minimals is that it permits many parallel installations (users like taco and me often have many 'independent' istallations (for projects) so, if the automatisms fail (i.e. you don't set TEXMF and TEXMFCNF yourself and depend on luatools cum suis to figure out where the configureations are) there is probably some interference with environment variables; i.e. when you for instance install tetex (or when the system came with it) you can be pretty sure that some variables are set and cf tds/kpse environment variables take precedence); in that case there is no way around overriding them at the shell level (as setuptex does) this also means that when you install the minimals allongside an existing tex installation, you probably still need to use setuptex
All such files will be read before any of the texmf.cnfs, and so they can be used to overrule texmf.cnf values, TEXMFCACHE in particular. The lua script has to return a table. Mine (I have only one) looks like this:
config = {} config.TEXMFCACHE = "/tmp" return config
there is an example contextcnf.lua file in the distribution that will have the variables that we support in addition to the normal ones in texmf.cnf ( Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Taco Hoekwater wrote:
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex]/texmf/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
I forgot to mention that in this case it will also set the texmf.cnf implicit variable $SELFAUTOPARENT to the single value that is the found TDS root (e.g. /opt/tex). For Hans: it makes sense to do this if TEXMFCNF *is* set as well. Best wishes, Taco
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Taco Hoekwater wrote:
Taco Hoekwater wrote:
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex]/texmf/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
I forgot to mention that in this case it will also set the texmf.cnf implicit variable $SELFAUTOPARENT to the single value that is the found TDS root (e.g. /opt/tex).
For Hans: it makes sense to do this if TEXMFCNF *is* set as well.
i think that this happens already,since i donnot test for the non-set case ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Taco Hoekwater wrote:
Later today (maybe already by the time you read this) there will be a new beta release in which mkiv (to be exact: luatools.lua, mtxrun.lua and the format-including luat-inp.lua) should be able to do without any environment variables, assuming the following condition is met:
This new release is available now. See http://wiki.contextgarden.net/Context_2008.05.21 for a few other changes in this release
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Hi Taco,
This new release is available now.
I've just had the chance to test this new release and got mixed results ... the 2008.05.21 minimal distribution (LuaTeX only) now sits in /usr/local/context/2008-05-21 and there's a symbolic link /usr/texbin -> /usr/local/context/2008-05-21/texmf-osx-intel/bin to the binaries. This link is given by the distribution switching mechanism on the Mac (see my earlier post in this thread) and is appended to $PATH, too. Furthermore, *no* TEXMFCNF environment variable is set. Now there's a problem of finding the texmf.cnf file: --- $>/usr/texbin/luatools --generate --verbose LuaTools | version 1.2.0 - 2006+ - PRAGMA ADE / CONTEXT LuaTools | variable SELFAUTOLOC set to /usr/texbin LuaTools | variable SELFAUTODIR set to /usr/texbin/.. LuaTools | variable SELFAUTOPARENT set to /usr/texbin/../.. LuaTools | variable TEXMFCNF set to {$SELFAUTODIR,$SELFAUTOPARENT}{,{/ share,}/texmf{-local,.local,}/web2c} LuaTools | no cnf files found (TEXMFCNF may not be set/known) LuaTools | LuaTools | runtime: 0.004 seconds --- The problem persists when I call the binary directly: --- $> /usr/local/context/2008-05-21/texmf-osx-intel/bin/luatools -- generate --verbose LuaTools | version 1.2.0 - 2006+ - PRAGMA ADE / CONTEXT LuaTools | variable SELFAUTOLOC set to /usr/texbin LuaTools | variable SELFAUTODIR set to /usr/texbin/.. LuaTools | variable SELFAUTOPARENT set to /usr/texbin/../.. LuaTools | variable TEXMFCNF set to {$SELFAUTODIR,$SELFAUTOPARENT}{,{/ share,}/texmf{-local,.local,}/web2c} LuaTools | no cnf files found (TEXMFCNF may not be set/known) LuaTools | LuaTools | runtime: 0.007 seconds --- Obviously, the problem is the symbolic link because LuaTeX tries and finds argv[0] in $PATH but doesn't resolve /usr/texbin to its actual location on disk. It's clear that in this situation there can't be any difference between the distribution-independent syntax of calling luatex and the direct invocation. Do you think LuaTeX's path discovery mechanism could be adapted to handle symbolic links? All the best, Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Obviously, the problem is the symbolic link because LuaTeX tries and finds argv[0] in $PATH but doesn't resolve /usr/texbin to its actual location on disk. It's clear that in this situation there can't be any difference between the distribution-independent syntax of calling luatex and the direct invocation.
Do you think LuaTeX's path discovery mechanism could be adapted to handle symbolic links?
there is lfs.symlinkattributes but i'm somewhat reluctant to usinmg platform specific things; if i have time i'll see if this function returns something useful Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hans Hagen wrote:
Oliver Buerschaper wrote:
Obviously, the problem is the symbolic link because LuaTeX tries and finds argv[0] in $PATH but doesn't resolve /usr/texbin to its actual location on disk. It's clear that in this situation there can't be any difference between the distribution-independent syntax of calling luatex and the direct invocation.
Do you think LuaTeX's path discovery mechanism could be adapted to handle symbolic links?
there is lfs.symlinkattributes but i'm somewhat reluctant to usinmg platform specific things; if i have time i'll see if this function returns something useful
No need, here is function that works and is portable to all platforms: function input.getownpath() local olddir = lfs.currentdir() if not input.ownpath then for p in string.gmatch(os.getenv("PATH"),"[^"..io.pathseparator.."]+") do lfs.chdir(p) p = lfs.currentdir() local b = file.join(p,input.ownbin) if lfs.isfile(b..".exe") or lfs.isfile(b) then input.ownpath = p break end end if not input.ownpath then input.ownpath = '.' end end lfs.chdir(olddir) return input.ownpath end Oliver, I have emailed you a patched version of luatools.lua. Can you try to make sure that it works for you as well? (It should, but ...) Best wishes, Taco
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi again, (replying to myself) Taco Hoekwater wrote:
Oliver, I have emailed you a patched version of luatools.lua. Can you try to make sure that it works for you as well? (It should, but ...)
Hans is just finished uploading a new beta that has two fixes in this area: * there was a bug in the TEXMFCACHE defaulting, making it ask strange questions if TEXMFCACHE was not set in texmfcnf.lua. * it comes with a variation of the symlink-discovering code I posted earlier. There is an extra report line if a symlink is followed while discovering the full executable path. e.g.: LuaTools | following symlink /home/taco/mybin to /usr/local/bin The chosen method has a few small flaws in bordercases that will be corrected eventually (in a new luatex release) but it seems to work well enough for now Best wishes, Taco
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Taco Hoekwater wrote:
The chosen method has a few small flaws in bordercases that will be corrected eventually (in a new luatex release) but it seems to work well enough for now
Before Oliver tells me I am being vague again: ;-) What I mean is this: in the full path "/usr/texbin/luatex", "texbin" can be a symlink to a different directory and that will be followed, but if "luatex" itself is a symlink to a file in a different directory, that will not be noticed. Solving that in pure lua is pretty hard, so I will add a predefined "full executable path" variable in the next luatex beta. Best wishes, Taco
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Hi Taco and Hans,
Before Oliver tells me I am being vague again: ;-)
Never mind :-)
What I mean is this: in the full path "/usr/texbin/luatex", "texbin" can be a symlink to a different directory and that will be followed, but if "luatex" itself is a symlink to a file in a different directory, that will not be noticed.
I think this should be just fine for the moment ... I've come across an interesting side effect of this new code though: I've just downloaded the new setup files for the minimals into a directory which happens to be outside a valid TDS tree. More precisely, I now have mtx-update.lua, mtxrun and texlua in /usr/local/ context/bin whereas the previous ConTeXt minimal resides in /usr/local/ context/2008-04-21. The symbolic link /usr/texbin points to the binaries directory in that distribution, i.e. ConTeXt-2008-04-21 is my currently active TeX distribution. Now when I issue the update command (or fetch command, that is) mtxrun wrongly believes it's located inside the /usr/local/context/2008-04-21 tree. For me (and the package building process) this doesn't seem to be relevant, but I have no idea whether there might be situations when this behaviour will turn out harmful. Isn't there a way of discovering the launch path (symbolic links already resolved) of an executable without resorting to $PATH? Another question: what part of the LuaTeX chain is responsible for locating the configuration files? Is it the scripts mtxrun.lua and luatools.lua or the binary texlua itself? You mentioned something about luatools only but now that Hans uploaded the entire beta ... Best, Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Another question: what part of the LuaTeX chain is responsible for locating the configuration files? Is it the scripts mtxrun.lua and luatools.lua or the binary texlua itself? You mentioned something about luatools only but now that Hans uploaded the entire beta ...
this is done in the lua code and taco and i spent quit esome time experimenting with this; our filosophy is to hard code as less as possible and let lud du the work unless this is not possible; here we have a border case with these symlinks; an option would to add functions that provide info about the symlink, but then, we don;t wan tto add too many functions to the core; hoever in this case it may be that we need to let the binary provide info about the path where the binary resides (also because it may be a bit playform depedent) (btw, the lua code is in luat-inp but merged into mtxrun and luatools so that these scripts can operate independent of libraries, because otherwise we can have another chicken or egg problem) at some point part of the interface in luat-inp will be public i.e. users can use it themselves, but first i need to clean up that code Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Another question: what part of the LuaTeX chain is responsible for locating the configuration files? Is it the scripts mtxrun.lua and luatools.lua or the binary texlua itself? You mentioned something about luatools only but now that Hans uploaded the entire beta ...
this is done in the lua code and taco and i spent quit esome time experimenting with this; our filosophy is to hard code as less as possible and let lud du the work unless this is not possible; here we have a border case with these symlinks; an option would to add functions that provide info about the symlink, but then, we don;t wan tto add too many functions to the core; hoever in this case it may be that we need to let the binary provide info about the path where the binary resides (also because it may be a bit playform depedent)
Who's "lud"?
(btw, the lua code is in luat-inp but merged into mtxrun and luatools so that these scripts can operate independent of libraries, because otherwise we can have another chicken or egg problem)
Good to know ...
at some point part of the interface in luat-inp will be public i.e. users can use it themselves, but first i need to clean up that code
Sure :-) Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hans Hagen wrote:
many functions to the core; hoever in this case it may be that we need to let the binary provide info about the path where the binary resides (also because it may be a bit playform depedent)
Side note: Finding the disk image that belongs to the current process is surprisingly hard on any Unix system. In bordercases, it may not even be present at all, because the executable can be deleted as soon as the process has started (it will still be present on disk, but nameless). Anyway, there is some special code in kpathsea that I can incorporate in the binary and that will make life much easier (once 0.30.0 is out) Best wishes, Taco
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
What I mean is this: in the full path "/usr/texbin/luatex", "texbin" can be a symlink to a different directory and that will be followed, but if "luatex" itself is a symlink to a file in a different directory, that will not be noticed.
I think this should be just fine for the moment ...
Extended report ... in short, format compilation fails because of file location problems. Apparently generating the LuaTeX cache succeeds though. See below. --- bash# luatools --generate --verbose LuaTools | version 1.2.0 - 2006+ - PRAGMA ADE / CONTEXT LuaTools | following symlink /usr/texbin to /usr/local/context/ 2008-05-24-beta/texmf-osx-intel/bin LuaTools | variable SELFAUTOLOC set to /usr/local/context/2008-05-24- beta/texmf-osx-intel/bin LuaTools | variable SELFAUTODIR set to /usr/local/context/2008-05-24- beta/texmf-osx-intel/bin/.. LuaTools | variable SELFAUTOPARENT set to /usr/local/context/ 2008-05-24-beta/texmf-osx-intel/bin/../.. LuaTools | variable TEXMFCNF set to {$SELFAUTODIR,$SELFAUTOPARENT}{,{/ share,}/texmf{-local,.local,}/web2c} LuaTools | loading configuration file /usr/local/context/2008-05-24- beta/texmf/web2c/texmfcnf.lua LuaTools | loading /usr/local/context/2008-05-24-beta/texmf/web2c/ texmf.cnf LuaTools | preparing configuration for /usr/local/context/2008-05-24- beta/texmf/web2c LuaTools | saving configuration in /usr/local/context/2008-05-24-beta/ texmf-cache/luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/ trees/01087b0ca69d21f3ef3ffa1e45445465.tma LuaTools | compiling configuration to /usr/local/context/2008-05-24- beta/texmf-cache/luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/ trees/01087b0ca69d21f3ef3ffa1e45445465.tmc LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- project LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- fonts LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- local LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- context LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- extra LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf LuaTools | scanning path /usr/local/context/2008-05-24-beta/texmf-local LuaTools | 0 files found on 0 directories with 0 uppercase remappings LuaTools | scanning path /usr/local/context/2008-05-24-beta/texmf- context LuaTools | 1349 files found on 125 directories with 0 uppercase remappings LuaTools | scanning path /usr/local/context/2008-05-24-beta/texmf LuaTools | 1550 files found on 82 directories with 60 uppercase remappings LuaTools | preparing files for /usr/local/context/2008-05-24-beta/texmf LuaTools | saving files in /usr/local/context/2008-05-24-beta/texmf- cache/luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 058e57e5173e90883a3ba926c33fe22d.tma LuaTools | compiling files to /usr/local/context/2008-05-24-beta/texmf- cache/luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 058e57e5173e90883a3ba926c33fe22d.tmc LuaTools | preparing files for /usr/local/context/2008-05-24-beta/ texmf-context LuaTools | saving files in /usr/local/context/2008-05-24-beta/texmf- cache/luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 3c541a92ee2a3a79f77458e195b0a0f8.tma LuaTools | compiling files to /usr/local/context/2008-05-24-beta/texmf- cache/luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 3c541a92ee2a3a79f77458e195b0a0f8.tmc LuaTools | preparing files for /usr/local/context/2008-05-24-beta/ texmf-local LuaTools | saving files in /usr/local/context/2008-05-24-beta/texmf- cache/luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 678bda37a3a32e3b1917a023bf896e91.tma LuaTools | compiling files to /usr/local/context/2008-05-24-beta/texmf- cache/luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 678bda37a3a32e3b1917a023bf896e91.tmc LuaTools | LuaTools | runtime: 0.255 seconds --- So far, so good. Now creating the format fails although the file texmf- context/tex/context/base/context.tex is present and perfectly readable :-( --- bash# luatools --ini --compile --verbose cont-en LuaTools | version 1.2.0 - 2006+ - PRAGMA ADE / CONTEXT LuaTools | following symlink /usr/texbin to /usr/local/context/ 2008-05-24-beta/texmf-osx-intel/bin LuaTools | variable SELFAUTOLOC set to /usr/local/context/2008-05-24- beta/texmf-osx-intel/bin LuaTools | variable SELFAUTODIR set to /usr/local/context/2008-05-24- beta/texmf-osx-intel/bin/.. LuaTools | variable SELFAUTOPARENT set to /usr/local/context/ 2008-05-24-beta/texmf-osx-intel/bin/../.. LuaTools | variable TEXMFCNF set to {$SELFAUTODIR,$SELFAUTOPARENT}{,{/ share,}/texmf{-local,.local,}/web2c} LuaTools | loading configuration file /usr/local/context/2008-05-24- beta/texmf/web2c/texmfcnf.lua LuaTools | loading configuration for /usr/local/context/2008-05-24- beta/texmf/web2c from /usr/local/context/2008-05-24-beta/texmf-cache/ luatex-cache/context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 01087b0ca69d21f3ef3ffa1e45445465 LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- project LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- fonts LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- local LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- context LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf- extra LuaTools | locating list of /usr/local/context/2008-05-24-beta/texmf LuaTools | loading files for /usr/local/context/2008-05-24-beta/texmf- local from /usr/local/context/2008-05-24-beta/texmf-cache/luatex-cache/ context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 678bda37a3a32e3b1917a023bf896e91 LuaTools | loading files for /usr/local/context/2008-05-24-beta/texmf- context from /usr/local/context/2008-05-24-beta/texmf-cache/luatex- cache/context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 3c541a92ee2a3a79f77458e195b0a0f8 LuaTools | loading files for /usr/local/context/2008-05-24-beta/texmf from /usr/local/context/2008-05-24-beta/texmf-cache/luatex-cache/ context/e09ab1c5fd12ff1663572f339200d7b9/trees/ 058e57e5173e90883a3ba926c33fe22d LuaTools | creating initialization file cont-en LuaTools | using library path : /usr/local/context/2008-05-24-beta/ texmf-context/tex/context/base LuaTools | using lua libraries: l-string.lua l-lpeg.lua l-table.lua l- boolean.lua l-number.lua l-set.lua l-unicode.lua l-md5.lua l-os.lua l- io.lua l-file.lua l-url.lua l-dir.lua l-utils.lua l-tex.lua luat- env.lua luat-lib.lua luat-inp.lua luat-tmp.lua luat-zip.lua luat-tex.lua LuaTools | using compiled initialization file cont-en.luc LuaTools | using lua initialization file cont-en.luc LuaTools | running command: luatex --ini --lua="cont-en.luc" "/usr/ local/context/2008-05-24-beta/texmf-context/tex/context/base/cont- en.tex" \\dump (/usr/local/context/2008-05-24-beta/texmf-context/tex/context/base/ cont-en.tex ! I can't find file `context.tex'. l.16 \input context.tex Please type another input file name: ^C bash# ! Emergency stop. l.16 \input context.tex mkiv lua stats : used config path - /usr/local/context/2008-05-24- beta/texmf/web2c/texmf.cnf mkiv lua stats : used cache path - /Users/oliver mkiv lua stats : input load time - 0.005 seconds mkiv lua stats : current memory usage - 612076 bytes mkiv lua stats : node memory usage - 1 dir --- Strangely LuaTeX seems to use yet another cache path during format generation. I'm puzzled. Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
What I mean is this: in the full path "/usr/texbin/luatex", "texbin" can be a symlink to a different directory and that will be followed, but if "luatex" itself is a symlink to a file in a different directory, that will not be noticed. I think this should be just fine for the moment ...
Extended report ... in short, format compilation fails because of file location problems. Apparently generating the LuaTeX cache succeeds though. See below.
the hashes differ (these hashes represent the original path of the subtree and are needed in order to run multiple trees in one cache) loading files for .../trees/678bda37a3a32e3b1917a023bf896e91 saving files in .../trees/058e57e5173e90883a3ba926c33fe22d loading files for .../trees/3c541a92ee2a3a79f77458e195b0a0f8 saving files in .../trees/3c541a92ee2a3a79f77458e195b0a0f8 loading files for .../trees/058e57e5173e90883a3ba926c33fe22d saving files in .../trees/678bda37a3a32e3b1917a023bf896e91 maybe you can add some message to caches.hashed caches.setpath and see what happens there (luat-tmp) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
What I mean is this: in the full path "/usr/texbin/luatex", "texbin" can be a symlink to a different directory and that will be followed, but if "luatex" itself is a symlink to a file in a different directory, that will not be noticed. I think this should be just fine for the moment ...
Extended report ... in short, format compilation fails because of file location problems. Apparently generating the LuaTeX cache succeeds though. See below.
taco and i are clueless ... we need more info -- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hans Hagen wrote:
Oliver Buerschaper wrote:
What I mean is this: in the full path "/usr/texbin/luatex", "texbin" can be a symlink to a different directory and that will be followed, but if "luatex" itself is a symlink to a file in a different directory, that will not be noticed. I think this should be just fine for the moment ... Extended report ... in short, format compilation fails because of file location problems. Apparently generating the LuaTeX cache succeeds though. See below.
taco and i are clueless ... we need more info
There is a new beta release now. It would be nice if you could delete all luatex-cache's on your disk and then try again. It is possible that there was a spurious file somewhere in the cache, what with all those changes we have made in the last week. Best wishes, Taco
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Extended report ... in short, format compilation fails because of file location problems. Apparently generating the LuaTeX cache succeeds though. See below.
taco and i are clueless ... we need more info
Will try and have a look at luat-tmp later the day and see whether I'll understand enough in order to implement your suggestion ... my knowledge of Lua is rather limited though. Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Extended report ... in short, format compilation fails because of file location problems. Apparently generating the LuaTeX cache succeeds though. See below. taco and i are clueless ... we need more info
Will try and have a look at luat-tmp later the day and see whether I'll understand enough in order to implement your suggestion ... my
Just ignore this suggestion, it is superseded by the new beta Best wishes, Taco
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Just ignore this suggestion, it is superseded by the new beta
Fresh attempt with version 2008.05.26 23:27 beta. Previously I wiped all instances of luatex-cache from my machine. As last time I didn't set any TEXMFCACHE environment variable and also placed the following texmfcnf.lua into texmf/web2c: --- config = {} config.TEXMFCACHE = "/usr/local/context/2008-05-26-beta/texmf-cache" return config --- This time generating the file database works but uses the wrong cache location. Apparently texmfcnf.lua is read but ignored. Format generation appears to run without flaws but keeps using the wrong cache. Please find logs of stdout attached ... By the way, you seem to have removed the stub "context" in texmf-osx- intel/bin. Instead I tried to run a test file using bash# mtxrun --script context test.tex directly but I'm afraid neither context nor mtx-context.lua can be found. See also: --- bash# luatools --variables TEXMFCACHE=/usr/local/context/2008-05-26-beta/texmf-cache bash# luatools --expansions TEXMFCACHE=/usr/local/context/2008-05-26-beta/texmf-cache bash# luatools --configurations TEXMFCACHE /usr/texbin/luatools:6527: attempt to call field 'tabstr' (a nil value) bash# luatools --find-file mtx-context.lua --verbose LuaTools | version 1.2.0 - 2006+ - PRAGMA ADE / CONTEXT LuaTools | following symlink /usr/texbin to /usr/local/context/ 2008-05-26-beta/texmf-osx-intel/bin LuaTools | variable SELFAUTOLOC set to /usr/local/context/2008-05-26- beta/texmf-osx-intel/bin LuaTools | variable SELFAUTODIR set to /usr/local/context/2008-05-26- beta/texmf-osx-intel LuaTools | variable SELFAUTOPARENT set to /usr/local/context/ 2008-05-26-beta LuaTools | variable TEXMFCNF set to {$SELFAUTODIR,$SELFAUTOPARENT}{,{/ share,}/texmf{-local,.local,}/web2c} LuaTools | loading configuration file /usr/local/context/2008-05-26- beta/texmf/web2c/texmfcnf.lua LuaTools | skipping configuration for /usr/local/context/2008-05-26- beta/texmf/web2c from /var/folders/d5/d5kShiN8Gla+FttIH2Kn4E+++TM/- Tmp-/luatex-cache/context/58e4229c51dae5be777b612e0e33b14d/trees/ 1e8cc3698917bc12bbc65c986d1f6576 LuaTools | LuaTools | LuaTools | runtime: 0.009 seconds --- Note that while file database and format generation were run as root the latter commands were called as a normal user. It that makes a difference. Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi Oliver, Oliver Buerschaper wrote:
/var/folders/d5/d5kShiN8Gla+FttIH2Kn4E+++TM/-Tmp-
How on earth did you manage to get this path? Is that $TMPDIR ? If so, it is probably different for each user, and in that case the distinction between root/user could be important. Best wishes, Taco
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
/var/folders/d5/d5kShiN8Gla+FttIH2Kn4E+++TM/-Tmp-
How on earth did you manage to get this path? Is that $TMPDIR ?
Exactly. $TMPDIR for my normal user account.
If so, it is probably different for each user, and in that case the distinction between root/user could be important.
Actually I've just realized that $TMPDIR isn't set for root. Most probably this is why LuaTeX chose my home folder (sudo -s made me root!) during database and format generation as its fall-back cache location because there was no $TMPDIR. Still, LuaTeX should've used the cache path specified in texmfcnf.lua in the first place. Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Actually I've just realized that $TMPDIR isn't set for root. Most probably this is why LuaTeX chose my home folder (sudo -s made me root!) during database and format generation as its fall-back cache location because there was no $TMPDIR. Still, LuaTeX should've used the cache path specified in texmfcnf.lua in the first place.
Just checking: does /usr/local/context/2008-05-26-beta/texmf-cache exist and is it writeable for everybody?
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Actually I've just realized that $TMPDIR isn't set for root. Most probably this is why LuaTeX chose my home folder (sudo -s made me root!) during database and format generation as its fall-back cache location because there was no $TMPDIR. Still, LuaTeX should've used the cache path specified in texmfcnf.lua in the first place.
Just checking: does
/usr/local/context/2008-05-26-beta/texmf-cache
exist and is it writeable for everybody?
It exists but used to have permissions 775 which were the ones rsync set. Changed them to 777 and retried database generation as normal user first. The directory above (set in texmfcnf.lua) is still ignored. Since $TMPDIR exists for a normal user LuaTeX chooses this one for its cache location. After wiping all luatex-cache directories from my machine I made another fresh attempt at database generation, this time as root. Again the cache settings in texmfcnf.lua are ignored and since there's no $TMPDIR for root LuaTeX resorts to $HOME. Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Actually I've just realized that $TMPDIR isn't set for root. Most probably this is why LuaTeX chose my home folder (sudo -s made me root!) during database and format generation as its fall-back cache location because there was no $TMPDIR. Still, LuaTeX should've used the cache path specified in texmfcnf.lua in the first place.
Just checking: does
/usr/local/context/2008-05-26-beta/texmf-cache
exist and is it writeable for everybody?
It exists but used to have permissions 775 which were the ones rsync set. Changed them to 777 and retried database generation as normal user first.
The directory above (set in texmfcnf.lua) is still ignored. Since $TMPDIR exists for a normal user LuaTeX chooses this one for its cache location.
After wiping all luatex-cache directories from my machine I made another fresh attempt at database generation, this time as root. Again the cache settings in texmfcnf.lua are ignored and since there's no $TMPDIR for root LuaTeX resorts to $HOME.
but is texmfcnf.lua loaded? (--verbose) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
but is texmfcnf.lua loaded? (--verbose)
Sure. Both for root and the normal user.
ok, another attempt .. new beta -- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
but is texmfcnf.lua loaded? (--verbose) Sure. Both for root and the normal user.
ok, another attempt .. new beta
Version 2008.05.27 16:31 happily generates the file database and compiles both english and dutch formats! Also, it sticks to the proper cache location I defined in texmf/web2c/texmfcnf.lua ... again without any environment variables set. Simple ConTeXt test files finally compile. Thanks very much for the effort you put into this crucial problem! Oliver P.S. Can you put that "context" stub back into the minimals?
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
On Wed, May 28, 2008 at 6:39 PM, Oliver Buerschaper wrote:
P.S. Can you put that "context" stub back into the minimals?
It's only missing in the scripts/context/stubs/unix/ folder, in scripts/context/stubs/mswin/ it is present :)
well, i copy a non existing unix stub into the zip is this one ok? #!/bin/sh mtxrun --script context "$@" Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
well, i copy a non existing unix stub into the zip
is this one ok?
#!/bin/sh mtxrun --script context "$@"
Perfect. It's exactly the one that used to be present in the beta 2008.05.24 20:06 (both in the binaries as well as the unix stubs directories). I was wondering why you removed it at all ;-) Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hans Hagen wrote:
Mojca Miklavec wrote:
P.S. Can you put that "context" stub back into the minimals? It's only missing in the scripts/context/stubs/unix/ folder, in
On Wed, May 28, 2008 at 6:39 PM, Oliver Buerschaper wrote: scripts/context/stubs/mswin/ it is present :)
well, i copy a non existing unix stub into the zip
is this one ok?
#!/bin/sh mtxrun --script context "$@"
Yup, will do nicely.
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
The directory above (set in texmfcnf.lua) is still ignored. Since $TMPDIR exists for a normal user LuaTeX chooses this one for its cache location.
Suddenly mine is ignored as well. Silly me, I should have tested that much earlier, sorry about that. Will get back to you.
![](https://secure.gravatar.com/avatar/a0f6b595b0e3b7f3abba19eeb8261fc2.jpg?s=120&d=mm&r=g)
taco and i are clueless ... we need more info
I think there is a problem with input.aux.expanded_path ... I have more or less the same system as Oliver, and this week-end I had the same problem as him, but with today's release I have a different one: (I changed only the PATH) # luatools --generate LuaTools | variable SELFAUTOLOC set to /Users/arthur/TeX/ConTeXt/tex/texmf-osx-intel/bin LuaTools | variable SELFAUTODIR set to /Users/arthur/TeX/ConTeXt/tex/texmf-osx-intel LuaTools | variable SELFAUTOPARENT set to /Users/arthur/TeX/ConTeXt/tex LuaTools | variable TEXMFCNF set to {$SELFAUTODIR,$SELFAUTOPARENT}{,{/share,}/texmf{-local,.local,}/web2c} LuaTools | no cnf files found (TEXMFCNF may not be set/known) LuaTools | LuaTools | runtime: 0.028 seconds Apparently the problem is to be traced back to input.aux.expanded_path, because it expands {$SELFAUTODIR,$SELFAUTOPARENT}{,{/share,}/texmf{-local,.local,}/web2c} into $SELFAUTODIR/share $SELFAUTODIR/texmf-local/web2c $SELFAUTODIR/texmf.local/web2c $SELFAUTOPARENT/share $SELFAUTOPARENT/texmf-local/web2c $SELFAUTOPARENT/texmf.local/web2c which is not correct, because it should also expand to .../texmf/... (see the trailing comma in {-local,.local,}). Arthur
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Arthur Reutenauer wrote:
taco and i are clueless ... we need more info
I think there is a problem with input.aux.expanded_path ... I have more or less the same system as Oliver, and this week-end I had the same problem as him, but with today's release I have a different one:
(I changed only the PATH)
i'll look into it ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/a0f6b595b0e3b7f3abba19eeb8261fc2.jpg?s=120&d=mm&r=g)
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex/texmf]/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
Thats's great! It works on my machine without the need to set any environment variable (I even tried two different arrangments of the directories). Arthur
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Arthur Reutenauer wrote:
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex/texmf]/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
Thats's great! It works on my machine without the need to set any environment variable (I even tried two different arrangments of the directories).
well, you need to set the path i assume -) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/a0f6b595b0e3b7f3abba19eeb8261fc2.jpg?s=120&d=mm&r=g)
well, you need to set the path i assume -)
Yes, sure :-) But it's much easier to control than all the variables set by setuptex. Now I can switch between the minimals and TeX Live by simply changing my PATH. Great! By the way, the rsync minimals have been updated, so it also works with them now. Arthur
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Arthur Reutenauer wrote:
well, you need to set the path i assume -)
Yes, sure :-) But it's much easier to control than all the variables set by setuptex. Now I can switch between the minimals and TeX Live by simply changing my PATH. Great!
By the way, the rsync minimals have been updated, so it also works with them now.
Be warned that this only affects mkiv for now. Last time I tried, texexec could not run without 4 or 5 variables (but admittedly that was quite a while ago, when it was still in perl). Best wishes, Taco
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Taco Hoekwater wrote:
Arthur Reutenauer wrote:
well, you need to set the path i assume -) Yes, sure :-) But it's much easier to control than all the variables set by setuptex. Now I can switch between the minimals and TeX Live by simply changing my PATH. Great!
By the way, the rsync minimals have been updated, so it also works with them now.
Be warned that this only affects mkiv for now. Last time I tried, texexec could not run without 4 or 5 variables (but admittedly that was quite a while ago, when it was still in perl).
it depends a bit on the logic; the previous code in luatools/mtxrun that tried to figure out the current location of the cnf file was derived from texmfstart which itself was based on older distributions; there have been changes in tds, names of trees, etc etc so texmfstart may as well be wrong there; 9it's one of those things i cannot test) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi, Hans Hagen wrote:
Taco Hoekwater wrote:
Arthur Reutenauer wrote:
well, you need to set the path i assume -) Yes, sure :-) But it's much easier to control than all the variables set by setuptex. Now I can switch between the minimals and TeX Live by simply changing my PATH. Great!
By the way, the rsync minimals have been updated, so it also works with them now.
Be warned that this only affects mkiv for now. Last time I tried, texexec could not run without 4 or 5 variables (but admittedly that was quite a while ago, when it was still in perl).
it depends a bit on the logic; the previous code in luatools/mtxrun that tried to figure out the current location of the cnf file was derived from texmfstart which itself was based on older distributions; there have been changes in tds, names of trees, etc etc so texmfstart may as well be wrong there; 9it's one of those things i cannot test)
I just tried texmfstart without any variables (but with adjusted PATH, of course), and it seems to work just fine here, much better than expected. I had to regenerate all my formats because the texmf-linux subtree is no longer part of the TEXMF searches, but after texexec --make all now seems to be fine (with the new formats in texmf-project). To other people: you may want to try this also. Perhaps setuptex has been obsolete for years without any of use realising it ;-) Best wishes, Taco
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Taco Hoekwater wrote:
To other people: you may want to try this also. Perhaps setuptex has been obsolete for years without any of use realising it ;-)
as mentioned before, setuptex is there to isolate trees -) there are now two methods to be wikified): (1) setuptex, if you have multiple trees with potential clashes due to existing trees (like old ones not using the current tex live structure) (2) setting the path, which works ok for distributions that are like tex live (i wonder what happens with those texmf.cnf files that ended up in /etc, but that may have been tetex which is obsolete now anyway) one of the problems is that although there is tds, the relative position of the binaries to the configuration file is not part of the standard but i think that we can safely say that we assume the relationship and don't support anything else (okay, one can set TEXMF and TEXMFCNF) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Arthur Reutenauer wrote:
well, you need to set the path i assume -)
Yes, sure :-) But it's much easier to control than all the variables set by setuptex. Now I can switch between the minimals and TeX Live by simply changing my PATH. Great!
hm, but that not much more keying than calling setuptex -) anyhow. i'm glad that it works (btw, it would be interesting to know to what extend linux/osx set up possible conflicting variables; when i made setuptex i had to take care of everything that a sysadm had set up (for instance in a project outside our company where the users has to deal with very old tex's hanging around and not being updated or lagging two years behind, and setuptex is then the only way to keep interference away) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/a0f6b595b0e3b7f3abba19eeb8261fc2.jpg?s=120&d=mm&r=g)
hm, but that not much more keying than calling setuptex -)
No, it's very different, because it's reversible: once you've sourced setuptex, there's no going back unless you unset dozens of variables. Up to now I had to use diiferent shells for TeX Live and the Minimals.
and setuptex is then the only way to keep interference away
Yes, that's definitely true. Arthur
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
(btw, it would be interesting to know to what extend linux/osx set up possible conflicting variables; when i made setuptex i had to take care of everything that a sysadm had set up (for instance in a project outside our company where the users has to deal with very old tex's hanging around and not being updated or lagging two years behind, and setuptex is then the only way to keep interference away)
On my machine (Mac OS X 10.5.2) with only the MacTeX distribution (TeX Live 2007 for Mac) installed no environment variable whatsoever is set that's related to TeX in any way ... I can't comment on older distributions though. Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
(btw, it would be interesting to know to what extend linux/osx set up possible conflicting variables; when i made setuptex i had to take care of everything that a sysadm had set up (for instance in a project outside our company where the users has to deal with very old tex's hanging around and not being updated or lagging two years behind, and setuptex is then the only way to keep interference away)
On my machine (Mac OS X 10.5.2) with only the MacTeX distribution (TeX Live 2007 for Mac) installed no environment variable whatsoever is set that's related to TeX in any way ...
Same here currently, but I have had many linuxes with TEXINPUTS set, sometimes without even a tex installed at all, and traditionally tex on dos/win needed a bunch of environment variables as well. But never mind that, all should be good now. Best wishes, Taco
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Wed, May 21, 2008 at 7:27 PM, Arthur Reutenauer wrote:
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex/texmf]/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
Mac (gwtex, mactex) also uses texmf.local. (Well, also many others, but that one is most evident.)
Thats's great! It works on my machine without the need to set any environment variable (I even tried two different arrangments of the directories).
I have just tested it and it didn't work as expected. MK II:
texexec --make --xtx --all TeXExec | using search method 'kpsewhich' TeXExec | updating file database mktexlsr: Updating /Users/mojca/context/tex/texmf/ls-R... mktexlsr: Updating /Users/mojca/context/tex/texmf-context/ls-R... mktexlsr: Updating /Users/mojca/context/tex/texmf-local/ls-R... mktexlsr: Done. TeXExec | using tex engine xetex TeXExec | using tex format path /Users/mojca/context/tex/texmf-context/web2c/xetex TeXExec | generating tex format cont-en This is XeTeX, Version 3.1415926-2.2-0.998.5-dev (Web2C 7.5.6) (INITEX) \write18 enabled. entering extended mode ... Beginning to dump on file metafun.mem (mem=metafun 2008.5.23) at most 3068 strings of total length 40865 49365 memory locations dumped; current usage is 12822&36400 1788 symbolic tokens Transcript written on metafun.log. TeXExec | TeXExec | tex engine path: /Users/mojca/context/tex/texmf-context/web2c/xetex TeXExec | mps engine path: /Users/mojca/context/tex/texmf-context/web2c TeXExec | TeXExec | tex: 23/05/2008 02:05:17 > /Users/mojca/context/tex/texmf-context/web2c/xetex/cont-en.fmt (4503548) TeXExec | tex: 23/05/2008 02:05:23 > /Users/mojca/context/tex/texmf-context/web2c/xetex/cont-nl.fmt (4544450) TeXExec | tex: 23/05/2008 02:05:25 > /Users/mojca/context/tex/texmf-context/web2c/xetex/mptopdf.fmt (1786949) TeXExec | mps: 23/05/2008 02:05:25 > /Users/mojca/context/tex/texmf-context/web2c/metafun.mem (491080) TeXExec | TeXExec | runtime: 15.745237
texexec --xtx a.tex TeXExec | processing document 'a.tex' TeXExec | no ctx file found TeXExec | tex processing method: context TeXExec | TeX run 1 TeXExec | writing option file a.top TeXExec | using randomseed 1213 TeXExec | tex engine: xetex TeXExec | tex format: cont-en This is XeTeX, Version 3.1415926-2.2-0.998.5-dev (Web2C 7.5.6) \write18 enabled. kpathsea: Running mktexfmt cont-en.fmt /usr/texbin/mktexfmt: line 336: /Users/mojca/context/tex/texmf/texconfig/tcfmgr: No such file or
(formats have always flied to texmf-osx-intel so far) But ... directory fmtutil: config file `fmtutil.cnf' not found. I can't find the format file `cont-en.fmt'! MK IV:
context a.tex
MtxRun | error unable to locate texmfcnf.lua MtxRun | loading configuration for /Users/mojca/context/tex/texmf/web2c from /Users/mojca/luatex-cache/context/bce2a35a5270714da084d11faf744f76/trees/71a1a190289e8fc90263c427daa9d235 MtxRun | locating list of /Users/mojca/context/tex/texmf-project MtxRun | locating list of /Users/mojca/context/tex/texmf-fonts MtxRun | locating list of /Users/mojca/context/tex/texmf-local MtxRun | locating list of /Users/mojca/context/tex/texmf-context MtxRun | locating list of /Users/mojca/context/tex/texmf-extra MtxRun | locating list of /Users/mojca/context/tex/texmf MtxRun | loading files for /Users/mojca/context/tex/texmf-local from /Users/mojca/luatex-cache/context/bce2a35a5270714da084d11faf744f76/trees/9cef58cec78e4ef962f7764cc0d0af77 MtxRun | loading files for /Users/mojca/context/tex/texmf-context from /Users/mojca/luatex-cache/context/bce2a35a5270714da084d11faf744f76/trees/05c539c10b6a70b446df0913d1c04b99 MtxRun | loading files for /Users/mojca/context/tex/texmf from /Users/mojca/luatex-cache/context/bce2a35a5270714da084d11faf744f76/trees/9cd0d756a20671533c8167942232650c MtxRun | using script: /Users/mojca/context/tex/texmf-context/scripts/context/lua/mtx-context.lua MtxRun | loading configuration for /Users/mojca/context/tex/texmf/web2c from /Users/mojca/luatex-cache/context/bce2a35a5270714da084d11faf744f76/trees/71a1a190289e8fc90263c427daa9d235 MtxRun | error no format found with name cont-en MtxRun | total runtime: 0.011 I definitely need to add texmfcnf.lua, but just a quick overview of non-working solutions :) Mojca
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
On Wed, May 21, 2008 at 7:27 PM, Arthur Reutenauer wrote:
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex/texmf]/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
Mac (gwtex, mactex) also uses texmf.local. (Well, also many others, but that one is most evident.)
Try this: if you run $ kpsewhich texmf.cnf when there are *no* variables set, what file does it return? Extending the lua function is easy, we just need to know how. Actually, I just tried that on my machine and it seems that it first tries three things we don't do: /opt/tex/texmf-linux/bin/texmf.cnf and /opt/tex/texmf-linux/texmf.cnf and /opt/tex/texmf.cnf the third of those should capture your file, right?
I have just tested it and it didn't work as expected.
MK II:
texexec --make --xtx --all
(formats have always flied to texmf-osx-intel so far)
This depends on your actual texmf.cnf settings. Likely they are not quite te same as the ENV variables used to be. Esp, check TEXFORMATS.
I can't find the format file `cont-en.fmt'!
Same issue here. To get back to what you used to have, you probably want these two in texmf.cnf: TEXMFOS = $SELFAUTODIR TEXFORMATS = .;$TEXMFOS/web2c/{$engine,} Best wishes, Taco
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Fri, May 23, 2008 at 9:13 AM, Taco Hoekwater
Mojca Miklavec wrote:
On Wed, May 21, 2008 at 7:27 PM, Arthur Reutenauer wrote:
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex/texmf]/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
Mac (gwtex, mactex) also uses texmf.local. (Well, also many others, but that one is most evident.)
Try this: if you run
$ kpsewhich texmf.cnf
when there are *no* variables set, what file does it return? Extending the lua function is easy, we just need to know how.
Actually, I just tried that on my machine and it seems that it first tries three things we don't do:
/opt/tex/texmf-linux/bin/texmf.cnf and /opt/tex/texmf-linux/texmf.cnf and /opt/tex/texmf.cnf
the third of those should capture your file, right?
Yes, thanks :) I only need to test this a bit more.
I have just tested it and it didn't work as expected.
MK II:
texexec --make --xtx --all
(formats have always flied to texmf-osx-intel so far)
This depends on your actual texmf.cnf settings. Likely they are not quite te same as the ENV variables used to be.
Esp, check TEXFORMATS.
TEXMF = {!!$TEXMFPROJECT,!!$TEXMFFONTS,!!$TEXMFLOCAL,!!$TEXMFCONTEXT,!!$TEXMFEXTRA,!!$TEXMFMAIN} TEXFORMATS = .;$TEXMF/web2c{/$engine,}
I can't find the format file `cont-en.fmt'!
Same issue here. To get back to what you used to have, you probably want these two in texmf.cnf:
TEXMFOS = $SELFAUTODIR TEXFORMATS = .;$TEXMFOS/web2c/{$engine,}
Great, thanks :) This works wonderful :) mkii is now (almost) setuptex-free? I need to check the rest, but I'm already fixing this one. Mojca
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
Which variables on this list are still needed? only mpmems? MFBASES = .;$TEXFORMATS MPMEMS = .;$TEXFORMATS TEXPOOL = .;$TEXFORMATS MFPOOL = .;$TEXFORMATS MPPOOL = .;$TEXFORMATS
from texmf.cnf, and $TMP doesn't exist on mac, Which is odd, to say the least. Where *do* temporary files go on OSX?
To /tmp, but there is no $TMP or $TEMP defined anywhere. Mojca
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Fri, May 23, 2008 at 9:59 AM, Taco Hoekwater wrote:
Mojca Miklavec wrote:
Which variables on this list are still needed? only mpmems?
Perhaps pdftex still needs TEXPOOL?
The minimals don't have any pool or mem files any more. (But I need to compile and uploda the "new" pdfTeX binaries for osx.) Mojca
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
Which variables on this list are still needed? only mpmems?
MFBASES = .;$TEXFORMATS MPMEMS = .;$TEXFORMATS
TEXPOOL = .;$TEXFORMATS MFPOOL = .;$TEXFORMATS MPPOOL = .;$TEXFORMATS
from texmf.cnf, and $TMP doesn't exist on mac, Which is odd, to say the least. Where *do* temporary files go on OSX?
i think that only mf still has a pool file (and probably also tex and etex and omega and aleph)
To /tmp, but there is no $TMP or $TEMP defined anywhere.
weird, maybe they use some apple name, like $WASTEBIN or $THRASH Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Fri, May 23, 2008 at 10:37 AM, Hans Hagen wrote:
Mojca Miklavec wrote:
Which variables on this list are still needed? only mpmems?
MFBASES = .;$TEXFORMATS MPMEMS = .;$TEXFORMATS
TEXPOOL = .;$TEXFORMATS MFPOOL = .;$TEXFORMATS MPPOOL = .;$TEXFORMATS
from texmf.cnf, and $TMP doesn't exist on mac,
Which is odd, to say the least. Where *do* temporary files go on OSX?
i think that only mf still has a pool file (and probably also tex and etex and omega and aleph)
As far as I know, Akira got rid of them in W32TeX (but not 100% sure).
To /tmp, but there is no $TMP or $TEMP defined anywhere.
weird, maybe they use some apple name, like $WASTEBIN or $THRASH
No. They use /tmp. I guess. Mojca
![](https://secure.gravatar.com/avatar/a0f6b595b0e3b7f3abba19eeb8261fc2.jpg?s=120&d=mm&r=g)
To /tmp, but there is no $TMP or $TEMP defined anywhere.
weird, maybe they use some apple name, like $WASTEBIN or $THRASH
We already had that discussion: very few systems actually set TMP or TEMP (the first public releases of Mark IV used to assume it was set, and subsequently created luatex-cache in the current directory since it wasn't). Arthur
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Arthur Reutenauer wrote:
To /tmp, but there is no $TMP or $TEMP defined anywhere. weird, maybe they use some apple name, like $WASTEBIN or $THRASH
We already had that discussion: very few systems actually set TMP or TEMP (the first public releases of Mark IV used to assume it was set,
few? afaik all windows and linux systems -)
and subsequently created luatex-cache in the current directory since it wasn't).
anyhow, taco and i decided now to default as follows: if CACHEPATH is not set: cachepath = os.env["TEXMFCACHE"] or os.env["TMP"] or os.env["TEMP"] or os.env["TMPDIR"] or os.get["HOME"] or os.env["HOMEPATH"] or nil in texmfcnf.lua one can set up his/her personal preferences (both taco and i use $TEMP cq. $TMP) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/a0f6b595b0e3b7f3abba19eeb8261fc2.jpg?s=120&d=mm&r=g)
few? afaik all windows and linux systems -)
No :-) I have to insist like one year ago, *no* Linux machine I have an account on does set TMP or TEMP (using various distributions). Maybe that's a shell problem, I don't know, but on any case you can't rely on it.
anyhow, taco and i decided now to default as follows: if CACHEPATH is not set:
cachepath = os.env["TEXMFCACHE"] or os.env["TMP"] or os.env["TEMP"] or os.env["TMPDIR"] or os.get["HOME"] or os.env["HOMEPATH"] or nil
Sounds reasonable, but why not test for the existence of the /tmp directory also? Arthur
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Arthur Reutenauer wrote:
few? afaik all windows and linux systems -)
No :-) I have to insist like one year ago, *no* Linux machine I have an account on does set TMP or TEMP (using various distributions). Maybe that's a shell problem, I don't know, but on any case you can't rely on it.
weird because what then is the purpose of that variable (ok, it may be that progs then put temp stuff all over the place which eventually will force you to buy an new machine so maybe some hidden interests)
anyhow, taco and i decided now to default as follows: if CACHEPATH is not set:
cachepath = os.env["TEXMFCACHE"] or os.env["TMP"] or os.env["TEMP"] or os.env["TMPDIR"] or os.get["HOME"] or os.env["HOMEPATH"] or nil
Sounds reasonable, but why not test for the existence of the /tmp directory also?
i'll consider it ... wold be funny if there is a tem pvar but no path ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Arthur Reutenauer wrote:
weird because what then is the purpose of that variable
But if there is no such variable, what's the point of looking for its purpose? :-) I suppose that on Unix, functions like mkstemp have to be preferred for truly temporary directories.
sure, but it depends on tmp being cleaned up too; afaik /tmp and c:/temp are only cleaned up periodically e.g. when one runs out of space so it's a kind of indication of 'may be cleaned up' anyhow, it makes even more sense on templess systems to set the texmfcache var (what i actually dislike is all this ~/.crap stuff which apart from not being that readable also give a fuzzy indication .. temp? hidden? weird? app-only?) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/d8110a8a8a97be0803549ea5ee2e638b.jpg?s=120&d=mm&r=g)
2008/5/23 Hans Hagen
sure, but it depends on tmp being cleaned up too; afaik /tmp and c:/temp are only cleaned up periodically e.g. when one runs out of space so it's a kind of indication of 'may be cleaned up'
Many Unixes clear /tmp at bootup. Even SUSE can do this. :-) http://en.wikipedia.org/wiki/Temporary_directory "In Unix and Linux, the global temporary directories are /tmp and /var/tmp. Typically, /var/tmp is for more permanent files, and /tmp is for more temporary files. See Filesystem Hierarchy Standard. In addition, a user can set his TMPDIR environment variable to point to a preferred directory (where the creation and modification of files is allowed)." Best Martin
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Martin Schröder wrote:
2008/5/23 Hans Hagen
: sure, but it depends on tmp being cleaned up too; afaik /tmp and c:/temp are only cleaned up periodically e.g. when one runs out of space so it's a kind of indication of 'may be cleaned up'
Many Unixes clear /tmp at bootup. Even SUSE can do this. :-)
http://en.wikipedia.org/wiki/Temporary_directory "In Unix and Linux, the global temporary directories are /tmp and /var/tmp. Typically, /var/tmp is for more permanent files, and /tmp is for more temporary files. See Filesystem Hierarchy Standard. In addition, a user can set his TMPDIR environment variable to point to a preferred directory (where the creation and modification of files is allowed)."
so then checking for TMPDIR should precece TMP ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Arthur Reutenauer wrote:
Sounds reasonable, but why not test for the existence of the /tmp directory also?
ok, to please you, i now stepwise test for existence; will b ein next beta upload Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/d8110a8a8a97be0803549ea5ee2e638b.jpg?s=120&d=mm&r=g)
2008/5/23 Arthur Reutenauer
To /tmp, but there is no $TMP or $TEMP defined anywhere.
weird, maybe they use some apple name, like $WASTEBIN or $THRASH
We already had that discussion: very few systems actually set TMP or TEMP (the first public releases of Mark IV used to assume it was set, and subsequently created luatex-cache in the current directory since it wasn't).
http://en.wikipedia.org/wiki/Temporary_directory http://en.wikipedia.org/wiki/TMPDIR "TMPDIR is the canonical Unix environment variable which points to user scratch space. Most Unix utilities will honor the setting of this variable and use its value to denote the scratch area for temporary files instead of the common default of /tmp. Other forms sometimes accepted are TEMP, TEMPDIR, and TMP but these are used more commonly by non-POSIX Operating systems." Best Martin
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
Which is odd, to say the least. Where *do* temporary files go on OSX? To /tmp, but there is no $TMP or $TEMP defined anywhere.
In Mac OS X 10.5.2 there's a $TMPDIR environment variable if that helps ...
when discussing the cache Arthur had a preference for HOME, so home is tested before TMPDIR personally i prefer TEMP || TMP || TMPDIR || HOME Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
when discussing the cache Arthur had a preference for HOME, so home is tested before TMPDIR
On a Mac the (persistent) user cache should probably go to a subdirectoy of $HOME/Library/Caches/ because this is where most applications store their cache data. Will have to check back with the Apple file system specification though ... Oliver
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Oliver Buerschaper wrote:
when discussing the cache Arthur had a preference for HOME, so home is tested before TMPDIR
On a Mac the (persistent) user cache should probably go to a subdirectoy of $HOME/Library/Caches/ because this is where most applications store their cache data. Will have to check back with the Apple file system specification though ...
in that case you need to set it up in texmfcnf.lua Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
On Wed, May 21, 2008 at 7:27 PM, Arthur Reutenauer wrote:
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex/texmf]/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
Mac (gwtex, mactex) also uses texmf.local. (Well, also many others, but that one is most evident.)
well, this is the chicken or egg problem .. of course we can go through two cycles (locate config, load config, filter only texmf from it, relocate again, maybe more cnf files, reload again, maybe even different texmf vars, locata another time, load again, ... etc) but for sure something else shows up then; the problem is that although there is a kind of standard (tds) there is no such standard for distributions ... the names of trees keep changing and we deciced to stick to texmf and texmf-local (the problem is that it does not get faster either, in theory setuptex is faster than just setting the path and figuring things out then for each run ... depends a bit on the system, network or not, etc)
Thats's great! It works on my machine without the need to set any environment variable (I even tried two different arrangments of the directories).
I have just tested it and it didn't work as expected.
you probably have a non typical system ... this approach assumes a simple tree setup with the main cnf in texmf or texmf-local ...
TeXExec | tex engine path: /Users/mojca/context/tex/texmf-context/web2c/xetex TeXExec | mps engine path: /Users/mojca/context/tex/texmf-context/web2c
that is something we don't want ... there is another autovar we need to set (i need to check texmfstart for it); setuptex sets up TEXOS and from that derives the path for formats; this makes it possible to use one three with different binaries (even different versions) for multiple platforms
(formats have always flied to texmf-osx-intel so far)
welcome to the mess ... kpse/web2c never had a provision for formats, i.e. the progs that generate the format need to sort out things, and then the env var (or var in texmf.cnf) have to locate it; in the worst case you end up with multiple fmt files .. you need to delete the ones in texmf-context once we get them in texmf-macosx again depending on the order (ok, setuptex just sets up *one* path, so that's safe but this is not the case with the cnf file)
MtxRun | error unable to locate texmfcnf.lua
no problem, you don't have one
I definitely need to add texmfcnf.lua, but just a quick overview of non-working solutions :)
hm, not needed, unless you want to set the cache Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
So, assuming /opt/tex/texmf-linux/bin, it attempts the following directories, in this order:
[/opt/tex/texmf]/web2c % two parents up [/opt/tex/texmf-linux]/texmf/web2c % one parent up [/opt/tex]/texmf-local/web2c [/opt/tex/texmf-linux]/texmf-local/web2c
Shouldn't local have some precedence over texmf? (Maybe I'm wrong.) Just a side note: Here I have the cnf file under /usr/local/gwTeX/texmf.cnf The binaries are under /usr/local/gwTeX/bin/i386-apple-darwin8.8.1 but I didn't test it on gwTeX yet. The main idea - cnf file will be overwritten by every update if it's only in texmf/web2c. The user needs to be able to put it either to texmf-local or to the top (at the same level where setuptex is), and that one needs to have precedence over the one in texmf. Unrelated - how exactly do I set TEXMFCACHE to be in texmf-cache alongside other texmf trees? I have tried (I know that this cannot work): TEXMFCACHE = '$TEXROOT/texmf-cache', but TEXROOT is probably unknown anyway Maybe it's still respecting the order in TEXMFCACHE = $TMP;$TEMP;$TMPDIR;$TEMPDIR;$HOME;$TEXMFVAR;$VARTEXMF;. from texmf.cnf, and $TMP doesn't exist on mac, so home is the first existing folder (where I hate to keep the cache - it should at least have a preceeding dot then). The only problem with mkii: basically works, but texexec --make puts formats under texmf-context and the kpathsea doesn't find them for some reason. If format is put under texmf-engine/web2c, everything works out of the box afterwards (with only path variable being set). Mojca
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
Unrelated - how exactly do I set TEXMFCACHE to be in texmf-cache alongside other texmf trees? I have tried (I know that this cannot work): TEXMFCACHE = '$TEXROOT/texmf-cache', but TEXROOT is probably unknown anyway
I forgot to finish the sentence: with this setting I get luatools --generate LuaTools | loading configuration file /Users/mojca/context/tex/texmf/web2c/texmfcnf.lua LuaTools | loading /Users/mojca/context/tex/texmf/web2c/texmf.cnfShould I create the cache path /texmf-cache? [yes|no] [no] every time, independent on whether I answer with yes or no. And everytime cache is generated under $HOME/luatex-cache. I guess that $TOXROOT is simply empty and /texmf-cache is not writable by me. Mojca
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
Unrelated - how exactly do I set TEXMFCACHE to be in texmf-cache alongside other texmf trees? I have tried (I know that this cannot work): TEXMFCACHE = '$TEXROOT/texmf-cache', but TEXROOT is probably unknown anyway
I forgot to finish the sentence:
with this setting I get
luatools --generate
LuaTools | loading configuration file /Users/mojca/context/tex/texmf/web2c/texmfcnf.lua LuaTools | loading /Users/mojca/context/tex/texmf/web2c/texmf.cnfShould I create the cache path /texmf-cache? [yes|no] [no]
every time, independent on whether I answer with yes or no. And everytime cache is generated under $HOME/luatex-cache. I guess that $TOXROOT is simply empty and /texmf-cache is not writable by me.
indeed, TEXROOT is an internal setuptex variable; actually, the only thing that setuptex sets up is TEXMF, TEXMFCNF, TEXFORMATS and TEXMFCACHE; the rest is nilling interfering variables and a few intermedia ones that save typing (TEXOS, TEXROOT) in the path bases variant, you cannot use TEXOS and TEXROOT since they don't exist; you can try TEXMFCACHE=/tmp ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Fri, May 23, 2008 at 9:34 AM, Hans Hagen wrote:
Mojca Miklavec wrote:
in the path bases variant, you cannot use TEXOS and TEXROOT since they don't exist; you can try TEXMFCACHE=/tmp
I know, but I do not want the cache to go to /tmp. It's still nice to be able to reuse it from time to time. Mojca
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
Here I have the cnf file under /usr/local/gwTeX/texmf.cnf
huh, in the root of the tree? is that also true for upcoming versions? i'm not sure if we should support all variants of trees and maybe gwtex assumes an env var to be set? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Fri, May 23, 2008 at 9:31 AM, Hans Hagen wrote:
Mojca Miklavec wrote:
Here I have the cnf file under /usr/local/gwTeX/texmf.cnf
huh, in the root of the tree? is that also true for upcoming versions? i'm not sure if we should support all variants of trees and maybe gwtex assumes an env var to be set?
In gwTeX there is only one variable, namely PATH is set to /usr/texbin, and that is a symlink to the proper version of binaries (/usr/local/gwTeX/bin/i386-apple-darwin8.8.1 in my case). Nothing else is needed, even though Oliver might explain more details if needed.
From what Taco explained, that configuration should already be OK.
Taco or Norbert: are there any plans to remove that /home/username from kpathsea search path? (the lowest possible priority though) Thanks, Mojca
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
On Fri, May 23, 2008 at 9:31 AM, Hans Hagen wrote:
Mojca Miklavec wrote:
Here I have the cnf file under /usr/local/gwTeX/texmf.cnf huh, in the root of the tree? is that also true for upcoming versions? i'm not sure if we should support all variants of trees and maybe gwtex assumes an env var to be set?
In gwTeX there is only one variable, namely PATH is set to /usr/texbin, and that is a symlink to the proper version of binaries (/usr/local/gwTeX/bin/i386-apple-darwin8.8.1 in my case). Nothing else is needed, even though Oliver might explain more details if needed.
From what Taco explained, that configuration should already be OK.
gwtex can have a patched default for TEXMFCNF (i.e the period instead of the -) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
In gwTeX there is only one variable, namely PATH is set to /usr/texbin, and that is a symlink to the proper version of binaries (/usr/local/gwTeX/bin/i386-apple-darwin8.8.1 in my case). Nothing else is needed, even though Oliver might explain more details if needed.
If I'm not mistaken this not only applies to gwTeX but rather to all TeX distributions on the Mac once MacTeX is installed. Although MacTeX looks like merely a repackaged TeX Live 2007 at first glance, it does come with an additional management structure for multiple TeX distributions. This additional layer consists both of a GUI part and a command line tool and is by itself completely independent of TeX Live. Unfortunately it's not yet distributed as an individual package (although this might change in the future). Anyway, as soon as a TeX distribution for the Mac brings along suitable information about itself this management layer will be able to seamlessly switch from one distribution to the next by adjusting only the symbolic link Mojca mentioned. In case you're wondering, for most old distributions that shipped before MacTeX this information is provided by the switching layer. This mechanism is most probably the reason why TeX Live 2007 doesn't leave any trail of environment variables behind and also why this would be highly undesirable for any TeX distribution on the Mac. Oliver
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi Mojca, (and Hans) Mojca Miklavec wrote:
Shouldn't local have some precedence over texmf? (Maybe I'm wrong.)
Yes (see below).
Unrelated - how exactly do I set TEXMFCACHE to be in texmf-cache alongside other texmf trees? I have tried (I know that this cannot work): TEXMFCACHE = '$TEXROOT/texmf-cache', but TEXROOT is probably unknown anyway
It is not (because texmfcnf.lua is read before everything else). There is SELFAUTOPARENT; I guess that is the only variable already defined at that point. TEXMFCACHE = '$SELFAUTOPARENT/texmf-cache', should work.
Maybe it's still respecting the order in TEXMFCACHE = $TMP;$TEMP;$TMPDIR;$TEMPDIR;$HOME;$TEXMFVAR;$VARTEXMF;.
Not that ordering *exactly* because texmf.cnf is not read yet, but a compiled-in version of that.
from texmf.cnf, and $TMP doesn't exist on mac,
Which is odd, to say the least. Where *do* temporary files go on OSX?
The only problem with mkii: basically works, but texexec --make puts formats under texmf-context and the kpathsea doesn't find them for some reason. If format is put under texmf-engine/web2c, everything works out of the box afterwards (with only path variable being set).
See above. Note: You may even have to run mktexlsr after format generation, because you are now totally at the mercy of the kpathsea library. ------------------------------------------------------------------- Mostly for Hans and mkiv, here is some more information about these AUTO-things: It turns out here are actually three variables, each a well-defined value, single value. Starting from the actual binary location, they are the relative paths: SELFAUTOLOC=. SELFAUTODIR=.. SELFAUTOPARENT=../.. And kpathsea uses these variables in a compile-time default of TEXMFCNF. My 'kpsewhich' actually tries for texmf.cnf in the following chain: /opt/tex/texmf-linux/bin /opt/tex/texmf-linux /opt/tex /opt/tex/texmf-linux/bin/share/texmf-local/web2c /opt/tex/texmf-linux /share/texmf-local/web2c /opt/tex /share/texmf-local/web2c /opt/tex/texmf-linux/bin/texmf-local/web2c /opt/tex/texmf-linux /texmf-local/web2c /opt/tex /texmf-local/web2c /opt/tex/texmf-linux/bin/share/texmf/web2c /opt/tex/texmf-linux /share/texmf/web2c /opt/tex /share/texmf/web2c /opt/tex/texmf-linux/bin/texmf/web2c /opt/tex/texmf-linux /texmf/web2c /opt/tex /texmf/web2c . /home/fmorel/Build/source/inst/texmf/web2c /home/fmorel/Build/source/inst/texmf/web2c And that is because my build/texk/kpathsea/texmf.cnf has TEXMFCNF = {$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}{,{/share,}/texmf{-local,}/web2c} The '.' is also useful methinks, but the two '/home/fmorel' ones are a bit of a fluke: they are added based on the user that ran autoconf, which is almost certainly irrelevant. At first glance, kpsewich seems it indeed finds only the first texmf.cnf, but that may be because I only have one :-) Best wishes, Taco
![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
Hi Taco, first of all, thanks very much for your long and detailed explanation! I appreciate very much what you and Hans have come up with during the last days. I'm afraid I haven't had time yet to try out the new configuration mechanism but I'm going to do so over the weekend and will get back to you afterwards ... In the meantime, some more thoughts of mine below ... ---
Yes, and even if we try really hard to not insert bugs, it simply cannot be helped. There is no regression test suite at the moment, and nobody seems motivated to create one. Hans and I certainly do not have time to set such a thing up.
But even if there was a test suite: it would likely run for days on end, so we could probably not afford to run it before each release in any case.
I agree that the appearance of bugs in complex systems cannot be avoided in principle. It's probably safe to accept this as a natural law ;-) On the possible running time of a regression test suite I can't comment at all simply because so far I haven't used any actively. From what I hear though wellknown open source projects tend to run any new code contributions against a test suite before they're actually committed to the main repository. Should this be impossible for every development version of ConTeXt, one could perhaps single out a suitable one as a release candidate and then run it against torture tests. It would then only be released after all bugs revealed by the regression test had been ironed out. TeX Live could be the target for such a process, or generally the standalone distributions tweaked for each platform. Given that there is a test suite, of course. Perhaps the easiest route to a regression test suite would be to promote the bug tracking system more actively among users: after all, with each reported bug comes a test file. Most tests would probably still require reduction but if flagged appropiately these might be a welcome challenge for the power users (they appear to isolate bugs on the mailing list anyway). Secondly, one would probably need a clear interface specification for ConTeXt in order to be sure what the exact result of a test should be. Maybe I've touched upon things which have already been tried and discarded. Also I might be overly optimistic. Still, comments and suggestions most welcome.
What we have so far only applies to mkiv, but doing a similar thing to texmfstart (and thereby all of mkii) should be relatively simple.
From what I've seen the MKII part of the minimals doesn't appear to need any environment variables. This applies at least to version 2008.04.18 which is the release I singled out by chance in order to figure out the details of wrapping up a Mac package. This is also where my confusion came from and why I started asking you about the situation in MKIV ... Best wishes, Oliver
![](https://secure.gravatar.com/avatar/1aaa8171e46f2c29d4441fa99a7fc634.jpg?s=120&d=mm&r=g)
On Mo, 19 Mai 2008, Mojca Miklavec wrote:
Any ideas if getting rid of dependency on environmental variables is doable?
And please also of that *stupid* user-specific luatex-cache. There must
be a way to run-time merge a system-wide luatex-cache with a
luatex-cache only for the user files.
like mktexlsr. Please do NOT reinvent the wheel formed like a
rectangle... see my other email.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Norbert Preining wrote:
On Mo, 19 Mai 2008, Mojca Miklavec wrote:
Any ideas if getting rid of dependency on environmental variables is doable?
And please also of that *stupid* user-specific luatex-cache. There must be a way to run-time merge a system-wide luatex-cache with a luatex-cache only for the user files.
i'll look into that when i have time (keep in mind that mkiv/luate xis rather fresh and not finished)
like mktexlsr. Please do NOT reinvent the wheel formed like a rectangle... see my other email.
actually, i *wanted* to get rid of mktexlsr cum suis ... for several reasons (1) more control (2) different file daabase models (at some point running from one zip file) (3) more speed (4) less platform issues kind trying to convert a square wheel to an elipse (much in tds/kpse is driven by 20 year old file systems and systems, kind of steam engine while now we have electricity) although it will not be noticeable in public distributions i want to support flatter file systems too (i.e. all files for a font in one path and so) but that should not bother you (hopefully) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
On Mon, May 19, 2008 at 9:03 AM, Taco Hoekwater wrote:
Norbert Preining wrote:
Well not surprising ... there is NO context script anywhere in the distribution!
Am I missing something? The script is:
scripts/context/lua/mtx-context.lua
If mtxrun cannot find it, something went wrong running
luatools --generate
It seems to me that this is actually a yet unanswered FAQ: - the thread about AucTeX on ntg-context
dunno, i never used emacs
- Oliver asked me about how to run LuaTeX without having to set any environmental variables except for PATH adjustment; that would make the mac installer much easier to cope with - in most TeX distributions, one simply puts texmf.cnf somewhere above the binary (selfautoparent trickery), and then everything works out of the box
i've come to hate this autofoo trickery since there is no resl standard and whatever one cooks up eventually something else happens
- similar question raised by Vyatcheslav for Windows
it would ne no problem if we could be sure that the binary lives relative to the tree (same for cnf file) but there is no clear policy for this (for instance on linux a cnf file can live somewhere under etc too)
- I often have problems in my editor; if I launch it from terminal with proper environmental variables set, then it works OK, but if I want to launch it from menu, then it sometimes works and sometimes not (some weird interference with the existing distribution, in most cases it just doesn't find the cont-en.fmt and stops there already)
I just wanted to raise the question as it appears in just every installation of TeX where one wants to use ConTeXt with LuaTeX.
As long as one runs source setuptex in minimals, or source ~/.luatex in Thomas' instructions of hard-coded paths then LuaTeX runs OK, but if one would like to run LuaTeX without explicitly setting environmental variables (problematic within TeX editors), one soon runs into problems.
mtxrun --tree=<pathtotree> should work given that there is a setuptex.tmf file there
Minimals contain texmf.cnf hidden somewhere in the tree. But even if I put in in the top folder, it doesn't help much. Hans also uses setuptex.tmf for reading settings with LuaTeX in some way, but again, it doesn't happen automatically.
indeed, since there is no robust way to locate it
Jonathan Kew also told me that it should be enough to have a proper version of texmf.cnf in the top folder, and then setting PATH to include binaries should be enough. LuaTeX now works on standalone ConTeXt installation for more than a year, but it would be nice to make it work on Debian, TeX Live, MikTeX (that will soon provide it) .... as well.
Any ideas if getting rid of dependency on environmental variables is doable?
i keep thinking about it but i'm not in the mood to implement a messy fuzzy logic solution thet eventually will bite us for instance, can you cook up a list of locations for each platform that is guaranteed correct? (no problem for the minimals probably)
PS: ping hans@miktex
hm Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/1aaa8171e46f2c29d4441fa99a7fc634.jpg?s=120&d=mm&r=g)
On Mo, 19 Mai 2008, Taco Hoekwater wrote:
If mtxrun cannot find it, something went wrong running
luatools --generate
Arggg... does that mean that anyone wanting to use simply
context
as a program as to set up all the luatex/context stuff, with independent
database etc etc?
That is a pain.
Again, you should definitely implement some level of global setup
possibility!!!
Either you want context in distributions, or we forget about that and
ask people to install context by themselves! It is impossible to setup a
context installation for MkIV in a decent way on a multi-user system. It
is simply *impossible* ATM.
I already suggested several times that there is a *system*wide*
luatex-cache which can be updated/regenerated everytime a distribution
package installs new files, very similar to mktexlsr.
Currently, every Debian package (and same with SuSE, RedHat, ...)
installing files into any TEXMFTREE afterwards calls mktexlsr so that
the files are available for any user.
Now that is *really* broken on context.
Again, if you want to be a system for strictly *single*user* systems,
please let me know and I will remove context from Debian ...
And probably from TeX Live, too. It cannot work like this.
AHHh, enough of my frustrated flames. Please don't take it personally.
But I have written again and again about that, and it seems nobody seems
to care nor to listen.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Norbert Preining wrote:
Arggg... does that mean that anyone wanting to use simply context as a program as to set up all the luatex/context stuff, with independent database etc etc?
indeed, mkiv will not use kpse; at some point i want to play with texmf.zip texmf-local.zip technically it's already possible but i need some more time to play with it
Again, you should definitely implement some level of global setup possibility!!!
you mean shared for users?
Either you want context in distributions, or we forget about that and ask people to install context by themselves! It is impossible to setup a context installation for MkIV in a decent way on a multi-user system. It is simply *impossible* ATM.
well, mkiv is still somewhat experimental ... if a day had more hours ...
I already suggested several times that there is a *system*wide* luatex-cache which can be updated/regenerated everytime a distribution package installs new files, very similar to mktexlsr.
i know, and its noted somewhere ...
Now that is *really* broken on context.
should kind of work for pdftex an xetex (in the past texexec even called fmtutil on a unix system but when thomas refused to support $engine i kicked that out)
Again, if you want to be a system for strictly *single*user* systems, please let me know and I will remove context from Debian ...
keep in mind that i hav eno experience with multi user systems (ok, long ago on vms) ... although on my linux boxes i have a user hagen, i'm always logged in as root -)
AHHh, enough of my frustrated flames. Please don't take it personally. But I have written again and again about that, and it seems nobody seems to care nor to listen.
come on, we do care, but it's a moving train ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/1aaa8171e46f2c29d4441fa99a7fc634.jpg?s=120&d=mm&r=g)
Hi Hans, On Mo, 19 Mai 2008, Hans Hagen wrote:
Again, you should definitely implement some level of global setup possibility!!!
you mean shared for users?
Yes.
keep in mind that i hav eno experience with multi user systems (ok, long
What we actually need, and that is the same for TeX Live and for all distributions (at least inmy imagination), is: - one (or several) system wide luatex cache thingies - one per user (if the user wants to) - a way to update the cache for specific trees only (luatools --system-only ...) - and the adaption of the lua functions that the different caches are merged at loading time, the later (user) taking precedence over the former. That would already be some big step forward.
come on, we do care, but it's a moving train ...
;-) Let me sometimes get rid of some frustration .... ;-))) It does not
happen often anyway.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
What we actually need, and that is the same for TeX Live and for all distributions (at least inmy imagination), is:
- one (or several) system wide luatex cache thingies - one per user (if the user wants to) - a way to update the cache for specific trees only (luatools --system-only ...) - and the adaption of the lua functions that the different caches are merged at loading time, the later (user) taking precedence over the former.
That would already be some big step forward.
come on, we do care, but it's a moving train ...
;-) Let me sometimes get rid of some frustration .... ;-))) It does not happen often anyway.
I really wonder how (if at all) LuaTeX is going to work on MikTeX ... :) ConTeXt is broken there already, and ConTeXt is the only tool that really benefits from LuaTeX (apart from some of your tools on TL). The new search capabilities are likely to break the MikTeX's auto-install functionality as well if nobody will push Hans to fix it (or implement it himself). Mojca
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
I really wonder how (if at all) LuaTeX is going to work on MikTeX ... :) ConTeXt is broken there already, and ConTeXt is the only tool that really benefits from LuaTeX (apart from some of your tools on TL). The new search capabilities are likely to break the MikTeX's auto-install functionality as well if nobody will push Hans to fix it (or implement it himself).
I meant to say: it's really great that you are putting so much effort to make LuaTeX work on non-ConTeXt-devoted installation. Without you, we would probably not see it present on TeX Live at least for the next year :) Thanks a lot for that! Mojca
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Mojca Miklavec wrote:
What we actually need, and that is the same for TeX Live and for all distributions (at least inmy imagination), is:
- one (or several) system wide luatex cache thingies - one per user (if the user wants to) - a way to update the cache for specific trees only (luatools --system-only ...) - and the adaption of the lua functions that the different caches are merged at loading time, the later (user) taking precedence over the former.
That would already be some big step forward.
come on, we do care, but it's a moving train ... ;-) Let me sometimes get rid of some frustration .... ;-))) It does not happen often anyway.
I really wonder how (if at all) LuaTeX is going to work on MikTeX ... :) ConTeXt is broken there already, and ConTeXt is the only tool that really benefits from LuaTeX (apart from some of your tools on TL). The new search capabilities are likely to break the MikTeX's auto-install functionality as well if nobody will push Hans to fix it (or implement it himself).
mixtex is another issue mostly because it uses a diferent approach; we had it working so at some point it will work again; probably not soon for luatex/mkiv but that's experimental anyway i simply have no capacity to run everything here (e.g. in order to set up a proper windows vm for testing i need additional windows licences which i don't have Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Norbert Preining wrote:
- one (or several) system wide luatex cache thingies - one per user (if the user wants to) - a way to update the cache for specific trees only (luatools --system-only ...) - and the adaption of the lua functions that the different caches are merged at loading time, the later (user) taking precedence over the former.
That would already be some big step forward.
for that to happen we need to define what system is and what is user in a pretty consistent and cross platform way (and not in the tetex n*m permutations way) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/1aaa8171e46f2c29d4441fa99a7fc634.jpg?s=120&d=mm&r=g)
On Mo, 19 Mai 2008, Hans Hagen wrote:
for that to happen we need to define what system is and what is user in a pretty consistent and cross platform way (and not in the tetex n*m permutations way)
system: TEXMFDIST TEXMFMAIN TEXMFLOCAL TEXMFSYSCONFIG TEXMFSYSVAR
user: TEXMFHOME TEXMFVAR TEXMFCONFIG
THat is how TL2008 will work on *ALL* supported platforms, including
windows.
TEXMFHOME = ~/texmf
where ~ -> $HOME on unix
~ -> %USERPROFILE% on win32
etc
Yes, till TL2007 we didn't have the distinction of SYS <-> non-SYS on
windows. But TL2008 will have exactely the same approach on all
platforms, including the same scripts (updmap-sys vs updmap, ...)
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Norbert Preining wrote:
On Mo, 19 Mai 2008, Hans Hagen wrote:
for that to happen we need to define what system is and what is user in a pretty consistent and cross platform way (and not in the tetex n*m permutations way)
system: TEXMFDIST TEXMFMAIN TEXMFLOCAL TEXMFSYSCONFIG TEXMFSYSVAR
i suppose that this is the order in $TEXMF in tex live then (on my machines and in the minimals we have a different order, i.e. local before main and so) just wondering ... how is a system wide update taking place (since local comes last) ... is the policy now "wipe out and install anew), if so, why still local?
user: TEXMFHOME TEXMFVAR TEXMFCONFIG
THat is how TL2008 will work on *ALL* supported platforms, including windows.
TEXMFHOME = ~/texmf where ~ -> $HOME on unix ~ -> %USERPROFILE% on win32 etc
Yes, till TL2007 we didn't have the distinction of SYS <-> non-SYS on windows. But TL2008 will have exactely the same approach on all platforms, including the same scripts (updmap-sys vs updmap, ...)
so eventually the mac is also consistent now Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/1aaa8171e46f2c29d4441fa99a7fc634.jpg?s=120&d=mm&r=g)
On Mo, 19 Mai 2008, Hans Hagen wrote:
system: TEXMFDIST TEXMFMAIN TEXMFLOCAL TEXMFSYSCONFIG TEXMFSYSVAR
i suppose that this is the order in $TEXMF in tex live then
No no no, that was the order in which the stuff came to my mind!!!
just wondering ... how is a system wide update taking place (since local comes last) ... is the policy now "wipe out and install anew), if so, why still local?
update in TeX Live will happen simply by removing a sub-package and
re-adding it, so the files will go normally to TEXMFDIST. But that
depends on what is in the package.
I don't understand with "wipe out and install anew"!? Yes, up to TL2007
every installation was practically a new one.
With 2008 we will have the ability to install updated package and also
other packages over the net into an already present installation.
For you and Taco it might be interesting that if you want you can even
set up some local repository and tell people to do:
tlmgr -location www.pragme-ade.nl/context-tl update
which will update the context package as shipped with TL to the one
shipped from your server.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Norbert Preining wrote:
Hi everyone,
aehmmm, looks nice, but
# let us see how the context wrapper looks like: $ cat /usr/bin/context #!/bin/sh
mtxrun --script context "$@"
# now see what mtxrun does ... $ mtxrun --script context foobar
MtxRun | unknown script: context $
Well not surprising ... there is NO context script anywhere in the distribution!
Am I missing something?
it's mtx-context.lua the --script looks for: (mtx-)context(s).lua in the current path or in the file database ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (8)
-
Arthur Reutenauer
-
Duncan Hothersall
-
Hans Hagen
-
Martin Schröder
-
Mojca Miklavec
-
Norbert Preining
-
Oliver Buerschaper
-
Taco Hoekwater