Hello, ** Hans Hagen [2018-08-24 16:39:54 +0200]: > On 8/24/2018 3:48 PM, Vladimir Lomov wrote: > >> I don't know why you get "damaged" pdf file (in fact how do you know >> that file is damaged?) but "TEXMFCNF" is special variable that I uses to >> tweak TeX Live configuration for my latex workflow but context >> (standalone and from TL) refuses to work if this variable is set (in >> terminal I do 'unset' while in Emacs I set its value to 'nil' because >> this is identical to "unset" it). The "TEXROOT" variable I found in >> update script, I'm not sure if context requires it to work but IMHO, it >> is harmless. And the last variable "TEXMFCACHE" I use to force context >> to use ~/.cache for "luatex-cache" directory and not "pollute" my home >> directory (without it the "luatex-cache" directory will be created in >> $HOME directory). > > context does listen to some of these variables but all lookups are done > independent of kpse,
And I suspect this causes strange behaviour of context in my case. I have $ echo $TEXMFCNF /home/vladimir/.texlive2018/texmf-config/web2c: The last colon is kpse feature to use not only the first texmf.cnf (https://www.tug.org/texinfohtml/kpathsea.html#Config-files) but all others (I use personal texmf.cnf to adjust some TEXMF variables for my latex workflow). With that TEXMFCNF context can't find its files (this is for context from TeX Live: -------------------------------- 8< ----------------------------------- mtxrun | forcing cache reload resolvers | resolving | looking for regular 'texmfcnf.lua' on given path '/home/vladimir/.texlive2018/texmf-config/web2c:' from specification '/home/vladimir/.texlive2018/texmf-config/web2c:' resolvers | resolving | looking for fallback 'contextcnf.lua' on given path '/home/vladimir/.texlive2018/texmf-config/web2c:' from specification '/home/vladimir/.texlive2018/texmf-config/web2c:' resolvers | resolving | resolvers | resolving | warning: no lua configuration files found resolvers | resolving | no texmf paths are defined (using TEXMF) resolvers | resolving | mtxrun | the resolver databases are not present or outdated resolvers | resolving | using suffix based filetype 'lua' resolvers | resolving | remembering file 'mtx-context.lua' using hash 'lua::mtx-context.lua' resolvers | resolving | using suffix based filetype 'lua' resolvers | resolving | remembering file 'mtx-contexts.lua' using hash 'lua::mtx-contexts.lua' resolvers | resolving | remembered file 'mtx-context.lua' resolvers | resolving | using suffix based filetype 'lua' resolvers | resolving | remembering file 'mtx-t-context.lua' using hash 'lua::mtx-t-context.lua' resolvers | resolving | using suffix based filetype 'lua' resolvers | resolving | remembering file 'mtx-t-contexts.lua' using hash 'lua::mtx-t-contexts.lua' resolvers | resolving | remembered file 'mtx-t-context.lua' resolvers | resolving | using suffix based filetype 'lua' resolvers | resolving | remembering file 'context.lua' using hash 'lua::context.lua' mtxrun | unknown script 'context.lua' or 'mtx-context.lua' -------------------------------- 8< ----------------------------------- ). I didn't try to figure out how to "fix" this, I simply unset that variable when I use context (both standalone and from TeX Live). > basically you only need to set the path or run context > / mtxrun with a full path, often from an editor > <pathtomtxrun>/mtxrun --script context .... > > works ok context script do exactly that. > Hans --- WBR, Vladimir Lomov -- If you ever want to have a lot of fun, I recommend that you go off and program an imbedded system. The salient characteristic of an imbedded system is that it cannot be allowed to get into a state from which only direct intervention will suffice to remove it. An imbedded system can't permanently trust anything it hears from the outside world. It must sniff around, adapt, consider, sniff around, and adapt again. I'm not talking about ordinary modular programming carefulness here. No. Programming an imbedded system calls for undiluted raging maniacal paranoia. For example, our ethernet front ends need to know what network number they are on so that they can address and route PUPs properly. How do you find out what your network number is? Easy, you ask a gateway. Gateways are required by definition to know their correct network numbers. Once you've got your network number, you start using it and before you can blink you've got it wired into fifteen different sockets spread all over creation. Now what happens when the panic-stricken operator realizes he was running the wrong version of the gateway which was giving out the wrong network number? Never supposed to happen. Tough. Supposing that your software discovers that the gateway is now giving out a different network number than before, what's it supposed to do about it? This is not discussed in the protocol document. Never supposed to happen. Tough. I think you get my drift.
signature.asc
Description: PGP signature
___________________________________________________________________________________ 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://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________
