> Date: Wed, 23 Sep 2026 22:29:47 +0200 > From: Patrice Dumas <[email protected]> > > On Wed, Sep 23, 2026 at 09:01:58PM +0100, Gavin Smith wrote: > > On Wed, Sep 23, 2026 at 09:32:11PM +0200, Patrice Dumas wrote: > > Could texi2any issue a warning if there is a directory component in the > > @setfilename argument? > > I would be ok in principle, but not if it is used by the emacs manuals. > > > Do you know if the Emacs build system relies on > > @setfilename (you said in another email it was "unused") or do they use -o? > > They use -o systemactically in their build system, both in the > Makefile.in and in the code generating the online manuals. Therefore, > the build system does not rely on the path in @setfilename. > > However, having the same leading directory used in the Makefile like > "-o dir/file" as in "@setfilename dir/file" ensures that a plain > > makeinfo manual.texi > > puts the Info file in the same place as the Makefile use would do.
Exactly. > > 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.) > > In my opinion, it would be better if a directory component in > @setfilename was ignored. In my opinion, it would be ideal if > @setfilename was ignored unless the Texinfo file is read from standard > input. We have to maintain backward compatibility, but I would be in > favor of deprecating @setfilename except for that specific use. Once again, such backward-incompatible changes should IMO and IME have very good reasons. What are those reasons in this case? Just the fact that this behavior might be surprising when you first hear about it?
