[twg-tds] scripts, enc/lig/map

[Hans Hagen]

At 00:49 20/02/2004, Reinhard Kotucha wrote:
> >>>>> "Hans" == Hans Hagen <pragma at wxs.nl> writes:
>
>     >    /scripts/context/perl/texexec.pl
>
>Maybe we end up in in a texmf/scripts tree which contains more
>directories than regular files.  Under the assumption that there
>should never be two files with the same name in texmf, the directories
>context and perl are not needed.  Subdirectories are useful if there
>are many files.

in context there are many files, and i will put even more scripts in the 
distribution; some of them use libraries and there i don;t want path 
clashes, think of:

/scripts/context/perl/texexec.pl
/scripts/context/perl/whatever.pl
/scripts/context/perl/whatever/one.pm  # used by whatever.pl
/scripts/context/perl/whatever/two.pm  # used by whatever.pl

so, i don't want to let the 'whatever' subpath and 'one.pm' clash with 
anything else

>  1. Maintenance:  if someone sends a patch, it is desirable to be
>     able to apply it once rather than walk through the directories and
>     overlook most of them.

we can prescribe that the zip containing the patch honors the tds structure

>  2. A modified script can be put into texmf-local or
>     texmf-use-with-care.

sure, since there can be

texmf/scripts
texmf-local/scripts

and local is searched before main

>  3. The way how a script is launched is system dependent even if the
>     script itself is not.  UNIX systems understand the comment
>     "#!/usr/bin/perl", others require to call perl with the name of
>     the script as an argument.
>
>     >> What about platform-dependent executable files (of an auxiliary
>     >> nature)?
>
>     > maybe
>
>     >    /scripts/{,$PLATFORM}/....

this is why there are wrappers in the bin paths; these can be system 
dependent (as are the other bins); the wrapper just lets kpse locat ethe 
script (texmf-local fo ran updated version, texmf when not found there)

>So the texmf tree is not platform independent anymore.  Ideally texmf
>trees from different distributions can be exchanged.  It would be a
>great advantage if I could install texmf trees from different
>distributions and can switch between them by setting an environment
>variable.

the idea is that the tree remains independent (while the bins + wrappers 
aren't); i've been using that model succesfully for years now

>It is very unlikely that I find somthing system dependent in MikTeX's
>texmf tree that works on my system.  It would be much better if the
>texmf tree remains platform independent.

eh ... perl scripts etc are usable for miktex as well

>And if Fabrice compiles texexec into a binary, I don't see any reason
>_not_ to put this at bin/Win32/texexec.exe.  IMHO this is the correct
>place.

such binaries eat up a lot of space; now i have:

windows: texexec.bat

   @echo off
   texmfstart texexec.pl %*

linux + macosx : texexec

#!/bin/sh

what=`echo $0 | sed 's at .*/@@'`

   p=`kpsewhich -progname=context -format='other text files' $what.pl`
   { test -n "$p" && test -f "$p"; } || { echo "\`$what.pl' not found."; 
exit 1; }

   perl "$p" "$@"

bit that could as well be(come):

  texmfstart texexec.pl $@

(texmfstart is a 'clever' launcher that is able to locate files in the 
texmf tree and launch them, not only scripts but also documentation files 
and so)

>Maybe texexec is not the best example.
>
>Paul, if you talk about
>
>     >  files (of an auxiliary nature)
>
>you certainly have something different in mind.  Probably something
>like Emacs' libexec directory which contains progs which are run by
>emacs but are never launched by a user directly.

this is indeed an application (editors, example framework, etc)

>If kpse can find out where an executable resides, it should be able to
>to find a subdirectory there, for instance
>
>/usr/local/bin/<PLATFORM>/libexec
>
>which is $SELFAUTOLOC/libexec.
>
>A reason not to have a program which is always called by an other
>program in $PATH is to avoid name clashes with other programs on a
>particular system.  I don't see another good reason.

sure

>Another problem:  What should $PLATFORM expand to under Linux?  Do I
>have to set an environment variable?  I can't say
>
>PLATFORM = Linux
>
>in texmf.cnf in a multi platform environment.

isn't that something which shoul dbe built into the kpse library itself?

>For bin/<PLATFORM> the value is determined by the configure script and
>I *have* to set an environment variable manually.
>
>And if there is really platform dependent stuff like machine language
>progs it is probably not sufficient to call it "Linux", maybe you have
>to call it "i368-linux-glibc2.2".
>
>As I said before, beeing able to switch between texmf trees from
>different distributions is very interesting.  The more I think about
>it the more I like it.

here i run multiple trees in paralel (old ones, new ones); also, i have

   texmf-linux   [bin|web2c]
   texmf-mswin   [bin|web2c]
   texmf-macosx  [bin|web2c]
   texmf-mswin-test ...

so that i can use different versions of binaries and pool files.

>The latest teTeX beta puts all the system independent files to
>texmf-dist.  Files generated by texconfig go to texmf.
>
>Thomas, shouldn't texmf-dist better be called texmf-tetex?
>
>With some modifications in texmf.cnf one could launch tex like
>
>TEXMFSYS=texmf-texlive tex myfile
>
>or even
>
>TEXMFSYS=texlive tex myfile

here i have setuptex for that -)

>Thomas, what do you think?  TEXMFDIST would be a better name for this
>env var, but unfortunately it's already in use.

as is TEXMFOS here -)

> >>>>> "Paul" == Paul Vojta <vojta at Math.Berkeley.EDU> writes:
>
>     > I'd also like to have this directory optional, at the discretion
>     > of the distribution maintainer.
>
>If the result of the discussion will be that texmf/scripts is useful
>then I don't think that it should be optional.
>
>If people understand what it is good for, they will use it.  If not,
>empty directories can be omitted anyway.

indeed

Hans