[tex-live] mysterious mpost problem

Hans Hagen pragma at wxs.nl
Wed Jan 19 18:21:31 CET 2005

Olaf Weber wrote:

> Basically, the problem seems related to the way the code infers a
> progname if the '-mem=foo' argument is given, and doesn't if '&foo' is
> used. 

that's a subtle differnece indeed

> - A partial solution is to always require the -progname for tex, mf,
>   mpost if a different progname than the name of the program is
>   desired.  This is easy to implement, though it may break backward
>   compatibility...  (Not that we're strangers to that; and I hope it
>   would complete the cleanup of that part of the options interface.)

dangerous to break that compatibility

> - For mpost in particular, it also appears that some values cannot be
>   safely used from the texmf.cnf for an existing mem, and therefore
>   should just be stored in the mem at dump time and used from there.
>   This is easy enough for me to do, if someone can tell me which ones.
> Storing the progname at dump in the mem file is not a solution for
> this particular problem.
> Explcitly specifying the progname option is safest.  The rule-of-thumb
> is that -progname should be -mem name, and since -mem name is adopted
> during runs not not during -ini, -progname needs to be explicit at
> -ini.

on the other hand, now one can share mem settings *which is what happens with 
context: many formats, one progname)

how about defaulting to the program name (binary) if -progname is missing?

[there are a few more such strange inconsistencies:

pdfetex + pdfetex.pool
mpost   + mp.pool      (i'd expect mpost.pool)

the same for names of dump formats. maybe all these things should default to the
binary's name]


                                           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

More information about the tex-live mailing list