That's a very good point; if the *user* specifices -o |... that
*should* override the security setting.
What if the -o option comes from a config file; should that override
the security setting? Probably not, because the override could
come from a .dvipsrc file created by a malicious program . .
only config files in trusted paths can be used for external commands etc.
Sounds like we're getting closer to Perl's taint mode.
In any case, this is the sort of thing we'd have to depend on
kpathsea to provide, right? I don't see that happening in this
release. Yet, not allowing
o !lpr
Dvips has *always* searched in the current directory first for virtually
all files, config files, tfm files, vf files, figure files, header files,
etc. So all the blame on that goes to me. This was intended as a
feature; users sometimes want to override something, much like TeX
searches for
Okay, so if we agree the solution is:
1. Allow the output pipe to be opened in all cases
and
2. Never search for configuration files (config.ps, config.printer,
and .dvipsrc are the only ones critical here) in the current
directory
then I've got some questions about dvips vs
I'd be content to apply that patch (to the TeXLive tree, which is the
current dvips `source' as far as I'm concerned) unless I hear any
objections . . .
-tom
I think that, it may actually be possible to support them if they fit
some really simple grammar of how they are used, or else automatic
conversion . . . that is, config.ps could say something like
allow command jpg2eps %f -
where %f means file name with no shell metacharacters or spaces or
