On 1.30-rc2 I made the following z.tex file: \catcode`\{=1 \catcode`\}=2 \edef\z{\the\eTeXversion} \dump Then I hit pdfetex -ini *z.tex and got This is pdfeTeXk, Version 3.141592-1.30.0-rc2-2.2 (Web2C 7.5.4) (INITEX) 22 JUL 2005 00:22 \write18 enabled. %&-line parsing enabled. **z.tex (./z.tex ! Undefined control sequence. l.3 \edef\z{\the\eTeXversion } Clues? Sorry, for the moment I can't try on rc3. BR, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
On Fri, 22 Jul 2005, Pawel Jackowski wrote:
On 1.30-rc2 I made the following z.tex file:
\catcode`\{=1 \catcode`\}=2 \edef\z{\the\eTeXversion} \dump
in fact also the other \lastnodetype, \eTeXrevision... don't work. It seems to be related to the check and(format_ident=" (INITEX)" , as it works if you make a link to pdfeinitex and call pdfeinitex *z No time now to check more. Regards, Hartmut
Hartmut Henkel wrote:
On Fri, 22 Jul 2005, Pawel Jackowski wrote:
On 1.30-rc2 I made the following z.tex file:
\catcode`\{=1 \catcode`\}=2 \edef\z{\the\eTeXversion} \dump
Then I hit
pdfetex -ini *z.tex
It's the shell:
pdfetex -ini \*z.tex
works :-)
ah .. clever .. typical an 'error' one can spend hours to uncover; looks like a design flaw to choose '*' for this. how about an --etex switch that acts as synonym for this * 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 -----------------------------------------------------------------
Pawel Jackowski wrote:
ah .. clever .. typical an 'error' one can spend hours to uncover; looks like a design flaw to choose '*' for this. how about an --etex switch that acts as synonym for this * Hans
I got `unrecognized option etex'
indeed; it's a feature request -) 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 -----------------------------------------------------------------
On 2005-07-22 09:22:03 +0200, Hans Hagen wrote:
ah .. clever .. typical an 'error' one can spend hours to uncover; looks like a design flaw to choose '*' for this. how about an --etex switch that acts as synonym for this *
Seems useful. -> Olaf Best Martin -- http://www.tm.oneiros.de
Pawel Jackowski wrote:
It's the shell:
pdfetex -ini \*z.tex
works :-)
The same shell with the same command works fine WITHOUT espace on pdfTeX 1.20a :(
Are you sure? Under bash, the behaviour of the pathname expansion can be somewhat controlled by a variable called nullglob: [taco@glenlivet context]$ shopt -p nullglob shopt -u nullglob [taco@glenlivet context]$ shopt -s nullglob [taco@glenlivet context]$ echo *pdftex [taco@glenlivet context]$ shopt -u nullglob [taco@glenlivet context]$ echo *pdftex *pdftex So perhaps that (or something like that) is what is causing the difference? Taco
On Fri, Jul 22, 2005 at 10:33:43AM +0200, Pawel Jackowski wrote:
It's the shell:
pdfetex -ini \*z.tex
works :-)
The same shell with the same command works fine WITHOUT espace on pdfTeX 1.20a :(
Perhaps your file z.tex is not in the current directory, but in
the search path of TeX input files. Then the shell may not find
a file that ends in "z.tex". In this case the "*" remains and
the program "pdfetex" gets as argument the unexpanded "*z.tex".
Yours sincerely
Heiko
Hi Heiko,
Perhaps your file z.tex is not in the current directory, but in the search path of TeX input files. Then the shell may not find a file that ends in "z.tex". In this case the "*" remains and the program "pdfetex" gets as argument the unexpanded "*z.tex".
Nope, I tried on the current directory. To summarize; under bash (linux or cygwin) environment and gcc as a builder, things are consistent, although seems to be mysterious. To be on safe side, a star should be quoted. Under windows the behaviour is environment/compiler dependent. Binaries made by M$ compiler behaves quite well; the star is not expanded anyhow by shell and is passed to TeX as is. Consequently, it CAN'T be quoted with backslash, since TeX reports `Undefined control sequence \*' then. Windows binaries made by gcc under cyg environment works like those under linux. That is the whole mystery. -etex commandline option will fix the inconsistency. BR, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
On Fri, Jul 22, 2005 at 04:44:07PM +0200, Pawel Jackowski wrote:
To summarize; under bash (linux or cygwin) environment and gcc as a builder, things are consistent, although seems to be mysterious. To be on safe side, a star should be quoted. Under windows the behaviour is environment/compiler dependent. Binaries made by M$ compiler behaves quite well; the star is not expanded anyhow by shell and is passed to TeX as is. Consequently, it CAN'T be quoted with backslash, since TeX reports `Undefined control sequence \*' then. Windows binaries made by gcc under cyg environment works like those under linux. That is the whole mystery. -etex commandline option will fix the inconsistency.
What about quoting with double quotes?
"*z.tex" instead of \*z.tex
Yours sincerely
Heiko
Pawel Jackowski wrote:
Hi Heiko,
Perhaps your file z.tex is not in the current directory, but in the search path of TeX input files. Then the shell may not find a file that ends in "z.tex". In this case the "*" remains and the program "pdfetex" gets as argument the unexpanded "*z.tex".
Nope, I tried on the current directory.
To summarize; under bash (linux or cygwin) environment and gcc as a builder, things are consistent, although seems to be mysterious. To be on safe side, a star should be quoted. Under windows the behaviour is environment/compiler dependent. Binaries made by M$ compiler behaves quite well; the star is not expanded anyhow by shell and is passed to TeX as is. Consequently, it CAN'T be quoted with backslash, since TeX reports `Undefined control sequence \*' then. Windows binaries made by gcc under cyg environment works like those under linux. That is the whole mystery. -etex commandline option will fix the inconsistency.
scripting languages suffer from this as well; by now i've learned never to trust command line globbing 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 -----------------------------------------------------------------
participants (6)
-
Hans Hagen -
Hartmut Henkel -
Heiko Oberdiek -
Martin Schröder -
Pawel Jackowski -
Taco Hoekwater