Is it possible to test the success of \write18, i.e. test if the shell
command has been executed by (La)TeX or disabled because of active
shell restrictions? I'm aware of the possibilities to test if the '-
shell-escape' option is enabled, disabled or set to the restricted
mode (\ifeof18, \pdfshellescape and the pdftexcmds package).
Things are easy when the shell escape option is enabled or disabled
However, in restricted mode I would like to know if the specific
command(s) I executed were permitted, i.e. have been added to the list
of trusted programs in `texmf.cnf` (for TeXLive).
The required information is already written into the log file:
runsystem(<command>)...executed safely (allowed).
Is there a way to test the success of \write18 calls in the code?
(Without hacks which parse the log file :-) )
I like to provide a user interface and report the success or failure
properly to the user.
Actually catching the return value of the \write18 call would be even
> Is it possible to test the success of \write18, i.e. test if the shell
> command has been executed by (La)TeX or disabled because of active
> shell restrictions? I'm aware of the possibilities to test if the '-
> shell-escape' option is enabled, disabled or set to the restricted
> mode (\ifeof18, \pdfshellescape and the pdftexcmds package).
> Things are easy when the shell escape option is enabled or disabled
> However, in restricted mode I would like to know if the specific
> command(s) I executed were permitted, i.e. have been added to the list
> of trusted programs in `texmf.cnf` (for TeXLive).
As you have aready said:
* \ifeof18 (disadvantage: you must know the feature exists, otherwise
TeX complains with an error).
* \pdfshellescape (pdfTeX) or \shellescape (XeTeX) with
values 0 (disabled), 1 (enabled), 2 (restricted)
AFAIK missing is:
* Restricted mode: Is a program is allowed without trying?
* Can the program be found?
* Return code of the program that is executed.
* Quoting specification for the command call.
> Actually catching the return value of the \write18 call would be even
* Make a feature request (pdfTeX, LuaTeX, XeTeX)
* Implement the feature request and provide patch files.
That raises the chances that the feature request is accepted
and actually added.
thanks for listing the missing features. I was looking for them and
couldn't find anything, but you can never be sure if you not just
I forgot to mention that I target pdf(La)TeX.
In LuaTeX it should be easily implementable using Lua code.
I have no idea about XeTeX.
I followed your advice and opened a feature request, at least for
I don't think I will find time to write a patch for it anytime soon.
I thought pdfTeX development was stopped, superseeded by LuaTeX which
provides all the primitives of pdfTeX...
Am i wrong ?
> Best Regards,
> Martin Scharrer
Yes. LuaTeX doesn't provide all of pdfTeX's primitives (otherwise the
pdftexcmds package would be unnecessary), and there are commits to
pdfTeX all the time (http://foundry.supelec.fr/gf/project/pdftex/). Of
course you could argue that now that LuaTeX is fairly stable and
omnipotent and can emulate every detail of pdfTeX and XeTeX, the latter
two could be regarded as effectevely superseded...
Change “LookInSig” to “tcalveu” to answer by mail.
» Development of PDFTeX has (in essence) stopped: the brave new world
» is to be LuaTeX.
Well, there *is* obviously at least some development (commits, bug
tracker items, Thanh responding on the mailing list...), but I don't
know whether that are only bug fixes. So the development has in essence
stopped in the sense "amount of LuaTeX development >> amount of pdfTeX
development," but not in the sense "the project has been completely
given up and nobody ever writes code for it."
:-( rewrite added to list, noting clarification in followup to yours:
+ status of pdftex project (aten't dead yet)
Robin Fairbairns, Cambridge
my address is @cl.cam.ac.uk, regardless of the header. sorry about that.