Re: [NTG-context] First hack at new ruby-aware texexec script for linux/unix

[Hans Hagen]

[EMAIL PROTECTED] wrote:
 This version runs the ruby scripts directly, rather than the suggested
 form, e.g., texfmstart pstopdf.rb file.ps.  I have no idea if that
 is intended to work -- it did in my very simple tests .  I'm not sure
 the RUBYLIB line is needed.
   
when you use texmfstart to launch a script, no rubylib is needed because  
libraries are loaded relative to the script; texmfstart itself (now) ships with 
the libraries that it needs embedded); when using the direct call (ruby 
path/texexec as from your script) should work equally well 

the reason why i made texmfstart are: 

- we don't need stubs for all scripts, which is esp handy when scripts bare 
names that may conflict with other things in ones path 

- texmfstart internally uses kpsewhich to locate the script (unless it is 
configured to use its internal kpse library and/or talks to kpse server); it 
tries hard to cache and carry over results which (depending on the machine and 
trees uses - large trees slow down kpsewhich) means that nested runs are 
faster, e.g. when texmfstart is used to start texexec, a nested texexec run 
starts up faster) 

- another reason why i made texmfstart is that it makes me less dependent of 
changes in tds (the change from /context/scripts/ruby to scripts/context/ruby 
in combination with different kpsewhich fmt flags gave me so much trouble 
(read: i had to use different stubs depending on what version of tes and 
kpsewhich were used and they were not always in sync) that i decided that a 
consistent 'texmfstart ...' stub was safest for me

- in the meantime texmfstart does a few more things, like tree initialixation 
and kpse expansion, think of: 

texmfstart xsltproc kpse:a.xsl --output=b.xml c.xml 

which will expand kpse: to the path as reported by kpsehwich. 

(here i use a mix: when running e.g. from other scripts or from editors i 
alwayss use texmfstart scriptname but when i run in the console i just use 
scriptname because windows can associate the .rb suffix with ruby (on unix one 
has to remove the suffix) 

it's all a matter of what suits best 

Hans 

-
  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
-

___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

[NTG-context] First hack at new ruby-aware texexec script for linux/unix

[gnwiii]

There are two classes of users:

1) most error messages are ignored up to and including the ones that
promise global thermonuclear war if you click on Yes, or

2) minor warnings bring all work to a halt until explained.

In honor of the latter class, who ask about the suggestion to use
texstart texexec.rb ...
when running context, the following script may be helpful.

TeX Live on linux runs texexec, etc. via a shell script that is linked
to the names of various
perl utilities.  Here is my first cut at a version that tries to use
the ruby scripts:

 --
#!/bin/sh
# use ruby and texmfstart.rb or perl
# to use: link to the names of ConTeXt scripts

what=`echo $0 | sed '[EMAIL PROTECTED]/@@'`

case $what in
texmfstart|texexec|pstopdf|textools|texutil)
  p=`kpsewhich -format=texmfscripts $what.rb`
  { test -n $p  test -f $p; } \
   || { echo \`$what.rb' not found.; exit 1; }
  RUBYLIB=${RUBYLIB:-${p%/*}}
  export RUBYLIB
  exec ruby $p ${1+$@}
  ;;
*)
  p=`kpsewhich -format=texmfscripts $what.pl`
  { test -n $p  test -f $p; } \
   || { echo \`$what.pl' not found.; exit 1; }
  exec perl $p ${1+$@}
  ;;
esac
 ---

This version runs the ruby scripts directly, rather than the suggested
form, e.g., texfmstart pstopdf.rb file.ps.  I have no idea if that
is intended to work -- it did in my very simple tests .  I'm not sure
the RUBYLIB line is needed.

-- 
George N. White III [EMAIL PROTECTED]
Head of St. Margarets Bay, Nova Scotia
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context