Difference between revisions of "Update Hints"

From Wiki
Jump to navigation Jump to search
 
m (fixed typos, enhanced formatting)
Line 1: Line 1:
Hans Hagen wrote in the mailing list at 2004-10-25:
+
''Hans Hagen wrote in the mailing list at 2004-10-25:''
  
 
In the latest TDS specs, scripts now reside under the <tt>../scripts</tt> path instead of under package entries (like <tt>../context</tt>).
 
In the latest TDS specs, scripts now reside under the <tt>../scripts</tt> path instead of under package entries (like <tt>../context</tt>).
  
One way to locate a script used to be to call <tt>kpsewhich</tt> with the format "other text files" but now the format is "texmfscripts".
+
One way to locate a script used to be to call ''kpsewhich'' with the format "other text files" but now the format is "texmfscripts".
  
 
The consequence of this is, that (combined with moved <tt>enc</tt> and <tt>map</tt> files in combination with strict paths in the [[texmf.cnf]] files), TeX distributions are not downward compatible. The assumption is more or less that users reinstall the whole lot and don't have their own fonts and such -)
 
The consequence of this is, that (combined with moved <tt>enc</tt> and <tt>map</tt> files in combination with strict paths in the [[texmf.cnf]] files), TeX distributions are not downward compatible. The assumption is more or less that users reinstall the whole lot and don't have their own fonts and such -)
  
Another change is the flattening of format suffixes to <tt>fmt</tt> (so make sure that you remove the efmt ones when you update binaries); although the spec suggests the usage of an <tt>$engine</tt> subpath (in order to distinguish formats) it looks like distributions will not implement this (too difficult).
+
Another change is the flattening of format suffixes to <tt>fmt</tt> (so make sure that you remove the <tt>efmt</tt> ones when you update binaries); although the spec suggests the usage of an <tt>$engine</tt> subpath (in order to distinguish formats) it looks like distributions will not implement this (too difficult).
  
 
The way context deals with that is the following:
 
The way context deals with that is the following:
Line 13: Line 13:
 
* you can use <tt>texmfstart</tt> (ruby script, win binary at our website) to launch a resource (document, script. whatever is supported)
 
* you can use <tt>texmfstart</tt> (ruby script, win binary at our website) to launch a resource (document, script. whatever is supported)
 
* you can use <tt>textools--fixtexmftree</tt> to convert an old to a new tree
 
* you can use <tt>textools--fixtexmftree</tt> to convert an old to a new tree
* you can use <tt>--engine</tt> (or set the var in [[texexec.ini]]) to use the $engine subpath conforming the TDS structure (unfortunately it looks like the $engine subpath will not be supported by [[texmf.cnf]] file; so much for standards)
+
* you can use <tt>--engine</tt> (or set the var in [[texexec.ini]]) to use the <tt>$engine</tt> subpath conforming the TDS structure (unfortunately it looks like the <tt>$engine</tt> subpath will not be supported by [[texmf.cnf]] file; so much for standards)
  
alternatively, one can (manually) adapt the [[texmf.cnf]] file (or have a partial copy in your local tree) that extends the enc + map paths to the old locations
+
Alternatively, one can (manually) adapt the [[texmf.cnf]] file (or have a partial copy in your local tree) that extends the enc + map paths to the old locations
  
Launching a script, can be done indirectly, using texmfstart, like
+
Launching a script, can be done indirectly, using ''texmfstart,'' like
  
  texmfstart texexec.pl ... args ...
+
<tt>  texmfstart texexec.pl ... args ...</tt>
  
 
or one can make a small stub, for instance:
 
or one can make a small stub, for instance:
  
  texmfstart --make texexec.pl
+
<tt>  texmfstart --make texexec.pl</tt>
  
and move the resulting bat file in one of your bin path. The texmfstart route is supposed to work with the old and new trees and future trees (since I will try to keep texmfstart downward compatible).
+
and move the resulting <tt>bat</tt> file in one of your <tt>bin</tt> path. The ''texmfstart'' route is supposed to work with the old and new trees and future trees (since I will try to keep ''texmfstart'' downward compatible).
  
on unix, it's hard to distinguish files by type, i.e. texexec can be a stub, perl script, binary, whatever; in this case, texmfstart will create a link(? end of line was missing)
+
On UNIX, it's hard to distinguish files by type, i.e. ''texexec'' can be a stub, perl script, binary, whatever; in this case, ''texmfstart'' will create a link''(? end of line was missing)''
  
Note that distributions have different means of locating scripts and resources, in which case you depend on the integrety of a distribution. In case of problems, you can always replace the stubs by texmfstart based stubs.
+
Note that distributions have different means of locating scripts and resources, in which case you depend on the integrety of a distribution. In case of problems, you can always replace the stubs by ''texmfstart'' based stubs.
  
Because of testing for tex live (which is the reference cross platfoirm tex distribution), i package the zips in the new structure and this means that users who have old trees and binaries may run into problems when they mix things.
+
Because of testing for TeXlive (which is the reference cross platform TeX distribution), I package the ZIPs in the new structure, and this means that users who have old trees and binaries may run into problems when they mix things.
  
[these changes in the enc/map file locations may give users who have their own font trees some headaches; also, if you use scripts in your own scripting tools e.g. in server apps, then you should be aware of the fact that locating scripts needs patches, i.e. the format fed to kpsewhich; here i have so many scripts that i don't put them all in the path, for instance because of name clashes, and i used to use kpsewhich to locate them; using texmfstart in such cases is more future safe, and with the coming new kpse run-as-deamon libraries it may become faster as well]
+
[These changes in the enc/map file locations may give users who have their own font trees some headaches; also, if you use scripts in your own scripting tools e.g. in server apps, then you should be aware of the fact that locating scripts needs patches, i.e. the format fed to ''kpsewhich;'' Here I have so many scripts that I don't put them all in the path, for instance because of name clashes, and I used to use ''kpsewhich'' to locate them; using ''texmfstart'' in such cases is more future safe, and with the coming new kpse run-as-deamon libraries it may become faster as well.]

Revision as of 14:44, 31 December 2004

Hans Hagen wrote in the mailing list at 2004-10-25:

In the latest TDS specs, scripts now reside under the ../scripts path instead of under package entries (like ../context).

One way to locate a script used to be to call kpsewhich with the format "other text files" but now the format is "texmfscripts".

The consequence of this is, that (combined with moved enc and map files in combination with strict paths in the texmf.cnf files), TeX distributions are not downward compatible. The assumption is more or less that users reinstall the whole lot and don't have their own fonts and such -)

Another change is the flattening of format suffixes to fmt (so make sure that you remove the efmt ones when you update binaries); although the spec suggests the usage of an $engine subpath (in order to distinguish formats) it looks like distributions will not implement this (too difficult).

The way context deals with that is the following:

  • you can use texmfstart (ruby script, win binary at our website) to launch a resource (document, script. whatever is supported)
  • you can use textools--fixtexmftree to convert an old to a new tree
  • you can use --engine (or set the var in texexec.ini) to use the $engine subpath conforming the TDS structure (unfortunately it looks like the $engine subpath will not be supported by texmf.cnf file; so much for standards)

Alternatively, one can (manually) adapt the texmf.cnf file (or have a partial copy in your local tree) that extends the enc + map paths to the old locations

Launching a script, can be done indirectly, using texmfstart, like

texmfstart texexec.pl ... args ...

or one can make a small stub, for instance:

texmfstart --make texexec.pl

and move the resulting bat file in one of your bin path. The texmfstart route is supposed to work with the old and new trees and future trees (since I will try to keep texmfstart downward compatible).

On UNIX, it's hard to distinguish files by type, i.e. texexec can be a stub, perl script, binary, whatever; in this case, texmfstart will create a link(? end of line was missing)

Note that distributions have different means of locating scripts and resources, in which case you depend on the integrety of a distribution. In case of problems, you can always replace the stubs by texmfstart based stubs.

Because of testing for TeXlive (which is the reference cross platform TeX distribution), I package the ZIPs in the new structure, and this means that users who have old trees and binaries may run into problems when they mix things.

[These changes in the enc/map file locations may give users who have their own font trees some headaches; also, if you use scripts in your own scripting tools e.g. in server apps, then you should be aware of the fact that locating scripts needs patches, i.e. the format fed to kpsewhich; Here I have so many scripts that I don't put them all in the path, for instance because of name clashes, and I used to use kpsewhich to locate them; using texmfstart in such cases is more future safe, and with the coming new kpse run-as-deamon libraries it may become faster as well.]