Here's what I had to do to update to the latest Context (2006.07.14) on Ubuntu 6.06 (i.e. 2006.06) distribution of Linux. It comes with tetex 3.0. The commands below assume a working Context already installed in your ~/texmf, and the commands use bash syntax, which is almost like 'sh' but has the ~ idiom for $HOME. Beforehand I had been using the 2006.04.17 beta and had put off upgrading because I was scared of the change from perl texexec to ruby texexec. 1. (optional cleanup) Delete the old Context-installed files in ~/texmf/. This step is optional, but I do it so that I can track the versions using an SCM. I use mercurial (hg is the program name), but it could have been svn, cvs, etc. The command (done in ~/texmf): hg locate -0 | xargs rm -0 2. (download, unpack) Download cont-tmf.zip, cont-fnt.zip, and cont-img.zip. Probably you need only the first zip file, but I'm reporting exactly what I did just in case any substep is the crucial one. The command: cd /tmp/ # no need to save them long-term wget http://www.pragma-ade.nl/context/current/cont-{tmf,fnt,img}.zip Unzip the zip archives into ~/texmf, appending the giant list of files to /tmp/a.log: cd ~/texmf for f in /tmp/cont-{tmf,fnt,img}.zip ; do unzip $f >> /tmp/a.log ;done 3. (stubs, part 1) Create ~/bin/texmfstart containing two lines: #!/bin/bash ~/texmf/scripts/context/ruby/texmfstart.rb "$@" Then make it executable with chmod +x ~/bin/texmfstart From what I can tell from reading the ruby code, using the full path to texmfstart.rb helps texmfstart.rb find the other .rb programs, like texexec.rb. (texmfstart.rb uses the path it was called with and looks in that directory, but Hans can correct me if I'm wrong here.) 4. (stubs, part 2) texmfstart will run texexec, so create texexec as a symlink to ~/texmf/scripts/context/stubs/unix/texexec: cd ~/bin ln -s ~/texmf/scripts/context/stubs/unix/texexec chmod +x texexec Hans: Could texexec be made executable in the distribution's zip file, to avoid the chmod? 5. (test 1) A first check is that texexec works. So change to a random directory, e.g. where you keep some Context files: cd ~/tmp/xy ; texexec --version That produces: TeXExec | version 6.2.0 - 1997-2006 - PRAGMA ADE/POD which looks good 6. (formats) Remake the formats with texexec --make --all 7. (test 2) Try a simple file. I use ~/tmp/xy/t.tex containing one line, "\starttext abc \stoptext". Here goes: texexec t fails with ! Font \*12ptrmtf*=ec-lmr12 not loadable: Metric (TFM) file not found. 8. (dreaded lmodern) Ack, it's the dreaded lmodern problem. I thought I had avoided this issue on my previous laptop, which ran Debian testing/unstable and got reincarnated as an Ubuntu laptop. And I had fixed it, by installing the 'lmodern' package. But Ubuntu lmodern is v0.92, at least as of Ubuntu 6.06, and Debian unstable uses v1.00, which includes the necessary .tfm files for ec-lmr*. The beta Ubuntu ('edgy eft') uses the new version, so I downloaded its .deb via http://packages.ubuntu.com, which eventually pointed me to a monster url and I did: cd /tmp wget http://ubuntu.mirrors.tds.net/ubuntu/pool/universe/l/lmodern/lmodern_1.00-2_... Note that the package version may change, so the easiest way is to download the latest .deb from http://ubuntu.mirrors.tds.net/ubuntu/pool/universe/l/lmodern/ Installing it is a bit painful. The first try (done as root) of dpkg -i /tmp/lmodern_1.00-2_all.deb complains with Usage error: unrecognized option Usage: update-fonts-dir DIRECTORY ... 'update-fonts-dir' is some X program that updates X's ideas of where its fonts are, and the package isn't calling it correctly. But I don't care whether X knows about the lmodern fonts, since I'm using them for documents viewed with gv or xpdf, not directly as an X font. So I shut up update-fonts-dir for the moment, installed, and undid the shutting up (all as root): chmod -x /usr/bin/update-fonts-dir dpkg -i /tmp/lmodern_1.00-2_all.deb chmod +x /usr/bin/update-fonts-dir 9. (test 2 again, not as root) Now 'texexec t' works fine, as does 'texexec --check' So I think all is well, and I didn't need to set RUBYLIB. Let me know of any corrections or improvements; if there's interest I'll wikifi.
From now on, I hope I can update using
texmfstart ctxtools --updatecontext -Sanjoy `A society of sheep must in time beget a government of wolves.' - Bertrand de Jouvenal
Sanjoy Mahajan wrote:
Here's what I had to do to update to the latest Context (2006.07.14) on Ubuntu 6.06 (i.e. 2006.06) distribution of Linux. It comes with tetex 3.0. The commands below assume a working Context already installed in your ~/texmf, and the commands use bash syntax, which is almost like 'sh' but has the ~ idiom for $HOME.
Updating context was one of the things on my todo list. great.
Beforehand I had been using the 2006.04.17 beta and had put off upgrading because I was scared of the change from perl texexec to ruby texexec.
1. (optional cleanup) Delete the old Context-installed files in ~/texmf/. This step is optional, but I do it so that I can track the versions using an SCM. I use mercurial (hg is the program name), but it could have been svn, cvs, etc. The command (done in ~/texmf):
hg locate -0 | xargs rm -0
2. (download, unpack) Download cont-tmf.zip, cont-fnt.zip, and cont-img.zip. Probably you need only the first zip file, but I'm reporting exactly what I did just in case any substep is the crucial one. The command:
cd /tmp/ # no need to save them long-term wget http://www.pragma-ade.nl/context/current/cont-{tmf,fnt,img}.zip
Unzip the zip archives into ~/texmf, appending the giant list of files to /tmp/a.log:
cd ~/texmf for f in /tmp/cont-{tmf,fnt,img}.zip ; do unzip $f >> /tmp/a.log ;done
3. (stubs, part 1) Create ~/bin/texmfstart containing two lines:
#!/bin/bash ~/texmf/scripts/context/ruby/texmfstart.rb "$@"
Then make it executable with
chmod +x ~/bin/texmfstart
From what I can tell from reading the ruby code, using the full path to texmfstart.rb helps texmfstart.rb find the other .rb programs, like texexec.rb. (texmfstart.rb uses the path it was called with and looks in that directory, but Hans can correct me if I'm wrong here.)
4. (stubs, part 2) texmfstart will run texexec, so create texexec as a symlink to ~/texmf/scripts/context/stubs/unix/texexec:
cd ~/bin ln -s ~/texmf/scripts/context/stubs/unix/texexec chmod +x texexec
Hans: Could texexec be made executable in the distribution's zip file, to avoid the chmod?
5. (test 1) A first check is that texexec works. So change to a random directory, e.g. where you keep some Context files:
cd ~/tmp/xy ; texexec --version
That produces:
TeXExec | version 6.2.0 - 1997-2006 - PRAGMA ADE/POD
which looks good
6. (formats) Remake the formats with
texexec --make --all
until here everything seems to work...
7. (test 2) Try a simple file. I use ~/tmp/xy/t.tex containing one line, "\starttext abc \stoptext". Here goes:
texexec t
fails with
! Font \*12ptrmtf*=ec-lmr12 not loadable: Metric (TFM) file not found.
on my machine this fails with:
$ texexec t.tex
TeXExec | processing document 't.tex'
TeXExec | no ctx file found
TeXExec | tex processing method: context
TeXExec | TeX run 1
TeXExec | writing option file t.top
TeXExec | using randomseed 1062
TeXExec | tex engine: pdfetex
TeXExec | tex format: cont-en
TeXExec | progname: context
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
(/home/ralf/texmf/web2c/natural.tcx)
entering extended mode
(./t.tex
ConTeXt ver: 2005.01.31 fmt: 2006.6.27 int: english mes: english
language : language en is active
8. (dreaded lmodern) Ack, it's the dreaded lmodern problem. I thought I had avoided this issue on my previous laptop, which ran Debian testing/unstable and got reincarnated as an Ubuntu laptop. And I had fixed it, by installing the 'lmodern' package. But Ubuntu lmodern is v0.92, at least as of Ubuntu 6.06, and Debian unstable uses v1.00, which includes the necessary .tfm files for ec-lmr*. The beta Ubuntu ('edgy eft') uses the new version, so I downloaded its .deb via http://packages.ubuntu.com, which eventually pointed me to a monster url and I did:
cd /tmp wget http://ubuntu.mirrors.tds.net/ubuntu/pool/universe/l/lmodern/lmodern_1.00-2_...
Note that the package version may change, so the easiest way is to download the latest .deb from http://ubuntu.mirrors.tds.net/ubuntu/pool/universe/l/lmodern/
Installing it is a bit painful. The first try (done as root) of
dpkg -i /tmp/lmodern_1.00-2_all.deb
complains with
Usage error: unrecognized option Usage: update-fonts-dir DIRECTORY ...
'update-fonts-dir' is some X program that updates X's ideas of where its fonts are, and the package isn't calling it correctly. But I don't care whether X knows about the lmodern fonts, since I'm using them for documents viewed with gv or xpdf, not directly as an X font. So I shut up update-fonts-dir for the moment, installed, and undid the shutting up (all as root):
chmod -x /usr/bin/update-fonts-dir dpkg -i /tmp/lmodern_1.00-2_all.deb chmod +x /usr/bin/update-fonts-dir
9. (test 2 again, not as root) Now 'texexec t' works fine, as does 'texexec --check'
So I think all is well, and I didn't need to set RUBYLIB. Let me know of any corrections or improvements; if there's interest I'll wikifi.
From now on, I hope I can update using
texmfstart ctxtools --updatecontext
does not work for me: $ texmfstart ctxtools --updatecontext kpsewhich: option `--expand-var' requires an argument CtxTools | updating CtxTools | unable to change to
-Sanjoy
Hi, Ralf Schmitt wrote:
Beforehand I had been using the 2006.04.17 beta and had put off upgrading because I was scared of the change from perl texexec to ruby texexec.
1. (optional cleanup) Delete the old Context-installed files in ~/texmf/. This step is optional, but I do it so that I can track the
I am not so sure that step is optional. Because if the preinstalled version had a cont-sys.tex or cont-usr.tex, then this step may be required to make sure you are not using an out-of-date version of these files.
3. (stubs, part 1) Create ~/bin/texmfstart containing two lines:
#!/bin/bash ~/texmf/scripts/context/ruby/texmfstart.rb "$@"
A somehwat more flexible version is #!/bin/sh ruby `kpsewhich --format='texmfscripts' texmfstart.rb` $@ (also notice the lack of quotes around $@)
4. (stubs, part 2) texmfstart will run texexec, so create texexec as a symlink to ~/texmf/scripts/context/stubs/unix/texexec:
cd ~/bin ln -s ~/texmf/scripts/context/stubs/unix/texexec chmod +x texexec
Hans: Could texexec be made executable in the distribution's zip file, to avoid the chmod?
ctxtools --update does that manually after unzipping, but sicne the zip is created on windows, the in-zip versions cannot be made executable AFAIK.
7. (test 2) Try a simple file. I use ~/tmp/xy/t.tex containing one line, "\starttext abc \stoptext". Here goes:
texexec t
fails with
! Font \*12ptrmtf*=ec-lmr12 not loadable: Metric (TFM) file not found.
In the future, the cont-lmt.zip may perhaps be re-instated.
ConTeXt ver: 2005.01.31 fmt: 2006.6.27 int: english mes: english
This is the old teTeX-supplied context format from January 31, 2005, that was last regenerated on June 27. Not the new one you created in the previous step.
So I think all is well, and I didn't need to set RUBYLIB. Let me know of any corrections or improvements; if there's interest I'll wikifi.
All documents that say you should set RUBYLIB are outdated and wrong. Every since texmfstart.rb is a 'fat' ruby script, that has become unnecesary.
From now on, I hope I can update using
texmfstart ctxtools --updatecontext
does not work for me:
$ texmfstart ctxtools --updatecontext kpsewhich: option `--expand-var' requires an argument
Do not worry about that until the rest of the install is correct, it may start working automagically. Taco
Taco Hoekwater wrote:
Hi,
Ralf Schmitt wrote:
texmfstart ctxtools --updatecontext
does not work for me:
$ texmfstart ctxtools --updatecontext kpsewhich: option `--expand-var' requires an argument
Do not worry about that until the rest of the install is correct, it may start working automagically.
I've tried texmfstart ctxtools --update yesterday with the same result on Fedora linux and it didn't start automagically :( It was missing $TEXMFLOCAL defined. Should ctxtools read texmf.cnf where this variable is definied or should it be defined somewhere else? It is a general question. For the moment I've defined it locally. BTW, it is confusing if old texexec says: warning : use 'texmfstart texexec' instead and Hans has created stubs which are called the same so finally one should use texexec (new one, which calls texmstart). What is a prefered command to refer to (mailing list, contextgarden)? texexec or texmfstart? Should ./scripts/context/perl/texexec.pl still be distributed? And should ./scripts/context/ruby/newtexexec.rb (and others new*.rb sripts) still be distributed if it significantly differs from newer ./scripts/context/ruby/texexec.rb Jano
Taco
Taco Hoekwater wrote:
Hi,
Ralf Schmitt wrote:
Beforehand I had been using the 2006.04.17 beta and had put off upgrading because I was scared of the change from perl texexec to ruby texexec.
1. (optional cleanup) Delete the old Context-installed files in ~/texmf/. This step is optional, but I do it so that I can track the
I am not so sure that step is optional. Because if the preinstalled version had a cont-sys.tex or cont-usr.tex, then this step may be required to make sure you are not using an out-of-date version of these files.
my texmf had been empty before. You're right. texexec had been using an old format file: $ kpsewhich cont-en.fmt /var/lib/texmf/web2c/cont-en.fmt I've deleted it (and also the old context directory). Now kpsewhich finds the right format file in ~/.texmf-var/.
ConTeXt ver: 2005.01.31 fmt: 2006.6.27 int: english mes: english
This is the old teTeX-supplied context format from January 31, 2005, that was last regenerated on June 27. Not the new one you created in the previous step.
now i've got the following output (which should be fine): ConTeXt ver: 2006.07.24 10:49 fmt: 2006.7.26 int: english mes: english
From now on, I hope I can update using
texmfstart ctxtools --updatecontext
does not work for me:
$ texmfstart ctxtools --updatecontext kpsewhich: option `--expand-var' requires an argument
Do not worry about that until the rest of the install is correct, it may start working automagically.
unfortunately it does not. Another problem might be that texexec --check complains about the nl format (actually I don't use it, en seems to work fine for me): TeXExec | progname: context This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (/home/ralf/texmf/web2c/natural.tcx) kpathsea: Running mktexfmt cont-nl.fmt mktexfmt: no info for format `cont-nl'. I can't find the format file `cont-nl.fmt'! TeXExec | runtime: 0.556275 TeXExec | end of analysis TeXExec | TeXExec | TeXExec | version 6.2.0 - 1997-2006 - PRAGMA ADE/POD TeXExec | TeXUtil | version 9.1.0 - 1997-2005 - PRAGMA ADE/POD TeXExec | CtxTools | version 1.3.3 - 2004/2006 - PRAGMA ADE/POD TeXExec | TeXExec | testing interface en TeXExec | pdfeTeX Version 3.141592-1.21a-2.2 (Web2C 7.5.4) TeXExec | ConTeXt ver: 2006.07.24 10:49 fmt: 2006.7.26 int: english mes: english TeXExec | TeXExec | testing interface nl TeXExec | format cont-nl.fmt does not work
1. (optional cleanup) Delete the old Context-installed files in ~/texmf/. This step is optional, but I do it so that I can track the
I am not so sure that step is optional. Because if the preinstalled version had a cont-sys.tex or cont-usr.tex, then this step may be required to make sure you are not using an out-of-date version of these files.
Good point, thanks. I'll incorporate it into the eventual wiki page.
A somehwat more flexible version is
#!/bin/sh ruby `kpsewhich --format='texmfscripts' texmfstart.rb` $@
(also notice the lack of quotes around $@)
According to the bash man entry: @ Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, each parameter expands to a separate word. That is, "$@" is equivalent to "$1" "$2" ... So if you ran texmfstart with texmfstart --option="hi there" then the $@ form would produce texmfstart.rb --option=hi there which would leave 'there' standing alone as a second argument. Whereas the "$@" form would produce texmfstart.rb "--option=hi there" This second form is what you want, no?
$ texmfstart ctxtools --updatecontext kpsewhich: option `--expand-var' requires an argument
Do not worry about that until the rest of the install is correct, it may start working automagically.
It didn't work magically, but Jano Kula's suggestion about TEXMFLOCAL made it work. I looked at the TEXMFLOCAL in the /etc/texmf/texmf.cnf and did: TEXMFLOCAL=/usr/local/share/texmf texmfstart ctxtools --updatecontext That worked fine except now there's version clash. During the update it said CtxTools | updating /usr/local/share/texmf and it downloaded the cont-tmf.zip there and unzipped it, remade the formats, and put them under ~/.texmf-var. So now the formats are based on the new context (2006.07.24) but for example, $ texmfstart ctxtools --contextversion CtxTools | context version: 2006.07.14 12:08 (/home/sanjoy/texmf/tex/context/base/context.tex) CtxTools | context version: 2006.07.14 12:08 (/home/sanjoy/texmf/tex/context/base/cont-new.tex) So texmfstart is finding the older source files in ~/texmf (from the 2006.07.14 update) although the formats themselves are newer. And trying a simple file gives: $ texexec t ... ConTeXt ver: 2006.07.14 12:08 fmt: 2006.7.26 int: english mes: english which worked fine, I guess since the two versions are sufficiently compatible. To avoid this problem, is it possible to put the new version in ~/texmf instead of in TEXMFLOCAL? Although in ~/texmf may be wrong for others, so it's a difficult problem... -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
Sanjoy Mahajan wrote:
Whereas the "$@" form would produce
texmfstart.rb "--option=hi there"
This second form is what you want, no?
Ah, I see. (is that bash-only?)
which worked fine, I guess since the two versions are sufficiently compatible. To avoid this problem, is it possible to put the new version in ~/texmf instead of in TEXMFLOCAL? Although in ~/texmf may be wrong for others, so it's a difficult problem...
Would it not work to simply point the variable TEXMFLOCAL to ~/texmf? Greetings, Taco
Whereas the "$@" form would produce
texmfstart.rb "--option=hi there"
This second form is what you want, no?
Ah, I see. (is that bash-only?)
It was hard to find a machine not running bash, a measure of the success of free software. But I eventually found a nearby Solaris machine running 'sh' (couldn't tell which version), but it's man entry says the same: if $@ is within a pair of double quotes, the positional parameters are substituted and quoted, separated by unquoted spaces ("$1""$2" ... ) So I think it's safe, and increases robustness, to change $@ -> "$@" in all the stub scripts.
Would it not work to simply point the variable TEXMFLOCAL to ~/texmf?
I was a little leery but tried it. Meanwhile here's a patch that fixes the need for that: --- a/scripts/context/ruby/ctxtools.rb Wed Jul 26 14:50:16 2006 -0400 +++ b/scripts/context/ruby/ctxtools.rb Wed Jul 26 14:53:57 2006 -0400 @@ -2314,7 +2314,7 @@ class Commands end def locatedlocaltree - return `kpsewhich --expand-var $TEXMFLOCAL`.chomp rescue nil + return `kpsewhich --expand-var '$TEXMFLOCAL'`.chomp rescue nil end def extractarchive(archive) The only problem is that it'll now, as intended, use the TEXMFLOCAL from texmf.cnf. But TEXMFLOCAL is probably not ~/texmf, so you'll still have to force the setting like this: TEXMFLOCAL=~/texmf texmfstart ctxtools --updatecontext The next problem was this message during the update: chmod: cannot access `scripts/context/unix/stubs/*': No such file or directory For my second attempt at ruby programming (the first being the two glorious quotes above), I looked to see what ctxtools.rb was doing around the chmod. It was supposed to report an error with this line: report("change x-permissions of '" + stubs + "' manually") But the line was not executed, because it was in a ruby 'rescue' clause. But when system("chmod +x ....") fails, it returns false, but does not throw an exception for rescue. So I rewrote the extractarchive() function to wrap the system() calls in if/unless clauses rather than rescue clauses. In doing so I noticed why the chmod failed: the path should be scripts/context/stubs/unix/* rather than scripts/context/unix/stubs/* The patch below does that change as well as the change of rescue -> if/unless. With these patches the automatic update went smoothly. One question: How safe is it that the ctxtools.rb script is overwritten by the unzip in the middle of running the script? Will ruby execute half from the old script and half from the new script? It wasn't an issue for me, I eventually realized, because the -u switch to unzip meant that my updated ctxtools.rb was not overwritten. But in general it will be. --- a/scripts/context/ruby/ctxtools.rb Wed Jul 26 14:54:24 2006 -0400 +++ b/scripts/context/ruby/ctxtools.rb Wed Jul 26 15:36:21 2006 -0400 @@ -2318,26 +2318,19 @@ class Commands end def extractarchive(archive) - if FileTest.file?(archive) then - begin - system("unzip -uo #{archive}") - rescue - report("fatal error, make sure that you have 'unzip' in your path") - return false - else - if System.unix? then - begin - system("chmod +x scripts/context/unix/stubs/*") - rescue - report("change x-permissions of 'scripts/context/unix/stubs/*' manually") - end - end - return true - end - else + unless FileTest.file?(archive) then report("fatal error, '{archive}' has not been downloaded") return false end + unless system("unzip -uo #{archive}") then + report("fatal error, make sure that you have 'unzip' in your path") + return false + end + stubs = "scripts/context/stubs/unix/*" + if System.unix? and not system("chmod +x " + stubs) then + report("change x-permissions of '" + stubs + "' manually") + end + return true end def remakeformats
Sanjoy Mahajan wrote:
It was hard to find a machine not running bash, a measure of the success of free software. But I eventually found a nearby Solaris machine running 'sh' (couldn't tell which version), but it's man entry says the same:
if $@ is within a pair of double quotes, the positional parameters are substituted and quoted, separated by unquoted spaces ("$1""$2" ... )
So I think it's safe, and increases robustness, to change $@ -> "$@" in all the stub scripts.
Many thanks for looking that up.
One question: How safe is it that the ctxtools.rb script is overwritten by the unzip in the middle of running the script? Will ruby execute half from the old script and half from the new script?
That is safe. Modern scripting languages normally byte-compile the entire file before running it (the main advantage is that this captures syntrax errors before any real harm is done). Taco
Sanjoy Mahajan wrote:
It was hard to find a machine not running bash, a measure of the success of free software. But I eventually found a nearby Solaris
more a measure of the lack of diversity ... imagine everyone living a house of the same design, driving the same car, etc etc 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 -----------------------------------------------------------------
Sanjoy Mahajan wrote:
Whereas the "$@" form would produce
texmfstart.rb "--option=hi there"
This second form is what you want, no?
Ah, I see. (is that bash-only?)
It was hard to find a machine not running bash, a measure of the success of free software. But I eventually found a nearby Solaris machine running 'sh' (couldn't tell which version), but it's man entry says the same:
if $@ is within a pair of double quotes, the positional parameters are substituted and quoted, separated by unquoted spaces ("$1""$2" ... )
coincidentaly i read this in the bash manual today but i was puzzled by it not being ("$1" "$2" ... ) # separated by spaces
So I think it's safe, and increases robustness, to change $@ -> "$@" in all the stub scripts.
i didn't follow this thread but i assume that at some point the outcome will be summarized; keep in mind that patched need to work for windows as well (different quoting) 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 -----------------------------------------------------------------
Is it possible to use more than one font size within a Natural Table? If so, how? Thanks, Neal
On 7/26/06, Neal Lester wrote:
Is it possible to use more than one font size within a Natural Table? If so, how?
Why not? But what exactly is your question/what do you want to do/what went wrong when you tried to use it? \setupTABLE[c][1][style=\bfb] \bTABLE \bTR\bTD abc\eTD\bTD def\eTD\eTR \eTABLE Mojca
("$1""$2" ... )
coincidentaly i read this in the bash manual today but i was puzzled by it not being
("$1" "$2" ... ) # separated by spaces
Sorry, my typo.
i didn't follow this thread but i assume that at some point the outcome will be summarized; keep in mind that patched need to work for windows as well (differ ent quoting)
How does Windows quoting work? Well, the whole story isn't needed, but only how would this ruby line `kpsewhich --expand-var '$TEXMFLOCAL'` differ on Windows relative to Unix? And the $@ -> "$@" change can be done in the Unix stubs only, so the change won't affect Windows (which uses .bat files and a different syntax). The other part of the patch was changing system() to be used within an if instead of a rescue block, and I got the return information about system() from the Programming Ruby manual online. It didn't say anything about it applying only to Unix, so that change should be safe too. -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
Sanjoy Mahajan wrote:
How does Windows quoting work? Well, the whole story isn't needed, but only how would this ruby line
`kpsewhich --expand-var '$TEXMFLOCAL'`
differ on Windows relative to Unix?
the problem is that one never knows when the shell does things and when the program does ... so in order to be really sure, we need taco to look into the kpse source to see if ' is handled there (here they are retained)
And the $@ -> "$@" change can be done in the Unix stubs only, so the change won't affect Windows (which uses .bat files and a different syntax).
so in texmfstart: f.write("#{program} #{callname} \"$@\"\012")
The other part of the patch was changing system() to be used within an if instead of a rescue block, and I got the return information about system() from the Programming Ruby manual online. It didn't say anything about it applying only to Unix, so that change should be safe too.
will look 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 -----------------------------------------------------------------
Hans Hagen wrote:
Sanjoy Mahajan wrote:
How does Windows quoting work? Well, the whole story isn't needed, but only how would this ruby line
`kpsewhich --expand-var '$TEXMFLOCAL'`
differ on Windows relative to Unix?
the problem is that one never knows when the shell does things and when
On unix, it is pretty easy to test what the shell does by pasting the stuff you want to try after the 'echo' command. In this case: $ echo kpsewhich --expand-var '$TEXMFLOCAL' kpsewhich --expand-var $TEXMFLOCAL I assume a similar trick is possible on windows, yes?
And the $@ -> "$@" change can be done in the Unix stubs only, so the change won't affect Windows (which uses .bat files and a different syntax).
so in texmfstart:
f.write("#{program} #{callname} \"$@\"\012")
Yes. That reminds me: I assume on MacOsX the same stubs will work except that \012 has to be changed into \015. Can someone test that? Cheers, taco
Sanjoy Mahajan wrote:
def locatedlocaltree - return `kpsewhich --expand-var $TEXMFLOCAL`.chomp rescue nil + return `kpsewhich --expand-var '$TEXMFLOCAL'`.chomp rescue nil end
returns 'result' here can you try: def locatedlocaltree tree = `kpsewhich --expand-path $TEXMFLOCAL`.chomp rescue nil unless tree && FileTest.directory?(tree) then tree = `kpsewhich --expand-path $TEXMF`.chomp rescue nil end return tree end (uses expand-path instead) 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 -----------------------------------------------------------------
It was hard to find a machine not running bash, a measure of the success of free software. But I eventually found a nearby Solaris
more a measure of the lack of diversity ... imagine everyone living a house of the same design, driving the same car, etc etc
Or instead walking, cycling, or taking public transit...but I dream.
can you try: ...
I ran this ruby script (on Linux): def locatedlocaltree tree = `kpsewhich --expand-path $TEXMFLOCAL`.chomp rescue nil unless tree && FileTest.directory?(tree) then tree = `kpsewhich --expand-path $TEXMF`.chomp rescue nil end return tree end print locatedlocaltree+"\n" and got the error due to lack of quotes around $TEXMF{,LOCAL}: kpsewhich: option `--expand-path' requires an argument kpsewhich: option `--expand-path' requires an argument Unix definitely needs those quotes to protect the variables in the backquoted command from the shell. Also the 'rescue nil' doesn't seem to have any effect. Probably similar to system(), the `cmd` construct doesn't raise an exception if the command fails or even isn't found. Instead you get tree equal to the empty string, since `` captures (the empty) stdout. Is path expansion (instead of variable expansion) a risky change? It might make tree a colon-separated list. That will cause trouble for the directory test in the 'unless' clause, and also break later uses of the returned value of locatedlocaltree that assume it is one path element. -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
Taco Hoekwater wrote:
Would it not work to simply point the variable TEXMFLOCAL to ~/texmf?
that should work 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 -----------------------------------------------------------------
ConTeXt ver: 2005.01.31 fmt: 2006.6.27 int: english mes: english
language : language en is active
system : cont-new loaded (/home/ralf/texmf/tex/context/base/cont-new.tex ! Undefined control sequence. l.14 \newcontextversion {2006.07.24 10:49} ? ! Emergency stop. l.14 \newcontextversion {2006.07.24 10:49} No pages of output. Transcript written on t.log. TeXExec | runtime: 1.705616 Any Ideas?
It looks like an old version of context is being used that doesn't understand the \newcontextversion command. And the line ConTeXt ver: 2005.01.31 fmt: 2006.6.27 int: english mes: english confirms the suspicion, because the ver: date is old and doesn't match the fmt: date. So somehow your old formats (.fmt files) are still being found by the searching. The Debian installation notes on the wiki has information on how to find and delete the old ones and fix up the config files. See the "Steps to finish a first context upgrade" section at http://wiki.contextgarden.net/Debian_installation and let me know if that fixes it. The Linux installation notes are overall a mess, partly made by me, so I'll try to clean them up once I understand the various interactions. -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
participants (7)
-
Hans Hagen -
Jano Kula -
Mojca Miklavec -
Neal Lester -
Ralf Schmitt -
Sanjoy Mahajan -
Taco Hoekwater