Yes, bash. And, as I said, after remaking the formats (shouldn't be necessary) mkii, but not mkiv, works on the mac. It's no problem for me: I never update the most recent working installation; I always install from scratch and only delete the old one when everything is working. Cheers, Jörg Aditya Mahajan wrote:

On Mon, 5 Oct 2009, Jörg Hagmann wrote:

...

Installing the minimals on ubuntu works with "first-setup.sh" without remaking the formats, in both mkII and mkiv.

Installing them on my mac (10.5.8) (same procedure), mkii only works after remaking the formats, whereas remaking them for mkiv didn't help (Fatal Error : Your format does not match the base files!).

Are you using the same shell in both. I vaguely remember that in some shells you need "source setuptex" while in others you need ". setuptex".

Aditya ------------------------------------------------------------------------

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

...

Yes, bash. And, as I said, after remaking the formats (shouldn't be necessary) mkii, but not mkiv, works on the mac.

You mean that on the mac:

luatools --generate context --make Yes. And the error: Fatal Error : Your format does not match the

base files!

does not create mkiv format. Do you get an error? Is the correct luatools being used? (i.e., does "which luatools" and "which luatex" point to the correct directory)

They exist and are found in texmf-osx-intel/bin Cheers, Jörg

luigi scarso wrote:

hmm -- I don't have osx , I have linux -- what about $> find minimals-beta -name "*.fmt" ? Assuming minimals-beta as root dir, I have them only under the cache, ie ./tex/texmf-cache/luatex-cache/context/e2d590ed08d5bb7ce264a85c7599601d/formats ./texmf-cache/luatex-cache/context/b111a13fc9cf27f239092c82f78b3124/formats/cont-en.fmt ./texmf-cache/luatex-cache/context/b111a13fc9cf27f239092c82f78b3124/formats/cont-nl.fmt ./texmf-cache/luatex-cache/context/b111a13fc9cf27f239092c82f78b3124/formats/mptopdf.fmt ./texmf-cache/luatex-cache/context/b111a13fc9cf27f239092c82f78b3124/formats/plain.fmt ./texmf-osx-intel/web2c/pdftex/cont-en.fmt ./texmf-osx-intel/web2c/pdftex/cont-nl.fmt ./texmf-osx-intel/web2c/pdftex/mptopdf.fmt ./texmf-osx-intel/web2c/xetex/cont-en.fmt ./texmf-osx-intel/web2c/xetex/cont-nl.fmt

Jörg

luigi scarso wrote:

ok put this in test.tex \starttext \input tufte \stoptext Then delete luatex-cache; $> cd ./tex/texmf-context/scripts/context/lua

why?

$> context --generate

luatools --generate?

$> context --make

mtx-context.lua:1358: attempt to call field 'extendbanner' (a nil value)

and try to $>context test.tex

mtx-context.lua:1358: attempt to call field 'extendbanner' (a nil value)

hmm , never see this. I believe that if you make a fresh minimals install and you have the same error, it's a minimals problem.

That's what I thought (I freshly installed twice). But I'll try again on Friday ... Thanks everybody. Jörg

On Tue, Oct 6, 2009 at 5:01 PM, luigi scarso wrote:

On Tue, Oct 6, 2009 at 5:00 PM, Jörg Hagmann wrote:

...

...

mtx-context.lua:1358: attempt to call field 'extendbanner' (a nil value)

hmm , never see this. I believe that if you make a fresh minimals install and you have the same error, it's a minimals problem.

That's what I thought (I freshly installed twice). But I'll try again on Friday ... Thanks everybody.

let's know.

sorry -- I mean: I think it's a bug, so

Let us know your progress -- luigi

On Tue, Oct 6, 2009 at 5:46 PM, Mojca Miklavec < mojca.miklavec.lists@gmail.com> wrote:

Just a remark. I didn't touch the Mac binaries for a long while (and my mac is already resting in peace, so I cannot test). Have any new binaries been released in the meantime?

I usually remove the "--make" switch (or it may be enough to call --keep switch once?) to prevent remaking formats at any given time if no updates are there. Is it possible that the make switch is turned out on your computer as well?

(Sorry, but I really cannot test what's going on on mac, though it's a bit strange that it behaves differently.)

Mojca

Hi mojca Did you rested well in the shade of the pyramids? -- luigi

Hans Hagen wrote:

can you search your disk (path) for other occurences of mtxrun and luatools? I have, in addition to the new attempt (context), the working installation I'm presently using (/Applications/newtex) and an older version (Applications/mytex). Both have their mtxrun and luatools:

./Applications/mytex/bin/mtxrun ./Applications/mytex/tex/texmf-osx-intel/bin/mtxrun ./Applications/newtex/bin/mtxrun ./Applications/newtex/tex/texmf-osx-intel/bin/mtxrun ./Users/bonasia/context/bin/mtxrun ./Users/bonasia/context/tex/texmf-context/scripts/context/stubs/unix/mtxrun ./Users/bonasia/context/tex/texmf-osx-intel/bin/mtxrun I tried the new installation under /Applications and then in my home directory, with the procedure "sh ./first-setup.sh" method ("simple instructions for installing on Unix-like systems"), and got the same result, namely: - For mkii the formats have to be made, but then it works - For mkiv, luatools --selfupdat, mtxrun --selfupdate and context give: bonasia:test$ luatools --selfupdate LuaTools | fileio: to be replaced old script /Users/bonasia/context/tex/texmf-osx-intel/bin/luatools LuaTools | fileio: unable to locate new script LuaTools | LuaTools | runtime: 0.051 seconds bonasia:test$ mtxrun --selfupdate MTXrun | fileio: to be replaced old script /Users/bonasia/context/tex/texmf-osx-intel/bin/mtxrun MTXrun | fileio: unable to locate new script bonasia:test$ context MTXrun | unknown script 'context.lua' or 'mtx-context.lua' Cheers, Jörg

On Wed, Oct 21, 2009 at 16:54, Jörg Hagmann wrote:

Mojca has sorted out my problems with minimal installations.  Since our correspondence was private, I would like to share the conclusions:

I had old and new installations and "source /path/oldtex/tex/setuptex /path/oldtex/tex" in the bash startup file (.profile or .bashrc). When I switched to the new installation, I changed TEXROOT (by source /path/newtex ...). This seems to generate a mixture of  TEX... variables, including some pointing to the "oldtex" installation.

Everything works fine if TEXROOT is set in a virgin shell that hasn't seen a "source ..." command yet.

According to Mojca, it's a bit more complicated. I copy her answer to my question, whether the above is correct:

Not completely. Copy and rename the old setuptex to the new distribution or the new setuptex to the old distribution (you need to rename it in order to prevent rewriting the file next time when you use it) or use something like   source /Applications/newtex/tex/setuptex ~/context/tex and it should work.

The reason for this weird behavior is that we removed almost all the variables from setuptex back in May 2009. This is just the contrary of what Hans tried to achieve several years ago to overwrite the tetex's pollution with variables. Now that hardly anyone uses tetex ... we didn't bother about that any more, but it is still a problem if one sets up an old distribution in .bashrc and then tries to use a new one. (In that case the old ConTeXt behaves just as impolitely as tetex and hinders the ability to use the latest one.) Mojca

On Sat, Oct 24, 2009 at 12:58, Hans Hagen wrote:

Mojca Miklavec wrote:

...

The reason for this weird behavior is that we removed almost all the variables from setuptex back in May 2009.

This is just the contrary of what Hans tried to achieve several years ago to overwrite the tetex's pollution with variables. Now that hardly anyone uses tetex ... we didn't bother about that any more, but it is still a problem if one sets up an old distribution in .bashrc and then tries to use a new one. (In that case the old ConTeXt behaves just as impolitely as tetex and hinders the ability to use the latest one.)

so, maybe we can add an extra script that resets these variables?

I would prefer to leave an option to users to set those variables themselves (at least to those who know what they are doing). Mojca