I would avoid modifying the list of programs allowed to run in the restricted shell. These are either programs that don't write out any output (and when output redirection is requested they don't work in the restricted shell escape setting) or respect the openout_any setting in texmf.cnf.
As far as the present problem is concerned, running pdflatex with shell escape enabled on the file filename.tex consists in using the command line
pdflatex -shell-escape filename
(no quotes).
How to setup a front-end to run this command depends on the front-end itself. With TeXShop, for example, one can define a new engine. In your ~/Library/TeXShop/Engines folder duplicate XeLaTeX.engine and call it pdflatexshell.engine. Modify the file (with TeXShop itself) to read
#!/bin/tcsh
set path= (/usr/texbin /usr/local/bin $path)
pdflatex -shell-escape "$1"
and, for a file you want to compile with unrestricted shell escape, write at its beginning
% !TEX TS-program = pdflatexshell
so that the engine will be automatically selected on opening.
What to do with other front-ends or LyX will vary.
If you really want to use the restricted shell escape, you have to enable
uname
rm
echo
latex
The program list can be determined by searching for runsystem in the .log file.
Best Answer
There's no real difference in how restricted and unrestricted shell-escape work as far as calling the operating system is concerned.
The unrestricted shell-escape is usually enabled, but it allows running only programs listed in a special variable set in
texmf.cnf; currently the list isThe restricted shell escape does not create a sandbox; the listed program are trusted not to be able to make uncontrolled reads and writes: they can only write in the current directory or below it, for instance. But in the end, the same system call as with the unrestricted shell-escape is performed.
You could add
latexandgsto the list, which is necessary forauto-pst-pdfto work, but this would open the same security problems as running the program with--shell-escape.The system calls generated by
auto-pst-pdfare equivalent to running the file throughso they should be safe. If other code in your document triggers system calls, then
--shell-escapecould be dangerous. Documents obtained from trusted sources (in particular written by you) shouldn't be risky. No package relying on--shell-escapehas, up to my knowledge, created problems. Of course there's always the possibility of receiving malicious code from untrusted sources.