On Wed, Sep 23, 2026 at 09:32:11PM +0200, Patrice Dumas wrote: > On Wed, Sep 23, 2026 at 02:45:13PM +0300, Eli Zaretskii wrote: > > > Date: Wed, 23 Sep 2026 11:18:34 +0200 > > > From: Patrice Dumas <[email protected]> > > > > > > I think that ignoring the directory from @setfilename when the -o > > > argument is determined to be a directory would be better, both more > > > useful, simpler and more consistent with -o with a file name as > > > argument. > > > > That might be better, but it is certain to break someone's setup out > > there, so MHO would be not to make such a change. > > The manual describes @setfilename argument as a base file name rather than > a path, so having a path in @setfilename should be considered as a > dangerous setup. It is never said explicitly that a path is wrong, > though, so it could happen, but I think that it is fair if the behaviour > changes (here in relation to -o) when it is confusing and inconsistent. > I actually thought that the directory part of path as @setfilename > argument was ignored, and I was quite surprised by the result.
Could texi2any issue a warning if there is a directory component in the @setfilename argument? Do you know if the Emacs build system relies on @setfilename (you said in another email it was "unused") or do they use -o? There could be a valid reason to have a directory component, but file names beginning with .. or which are absolute (beginning with /) do seem dangerous (as I said in the recent email thread about copying images for HTML output) -- this could be used by a malicious actor to overwrite files, for example. (I'm not aware of this happening in practice or any specific exploit, though.)
