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.