On Thu, Sep 24, 2026 at 08:49:48AM +0300, Eli Zaretskii wrote: > > 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.
As you say it is long-standing behaviour and deterministic, so I do not think there is an major problem with texi2any using directory components in the @setfilename argument. In my opinion it is a usage that is difficult to understand and which has a surprising effect, but those are problems for projects with such manuals, not the problems of the Texinfo project. They chose to have @setfilename lines in their Texinfo manuals pointing to higher-level directories so can deal with any confusion that may ensue. I'm open to the idea of texi2any issuing a warning if a file is placed in a non-standard location due to a @setfilename occuring in the input. I would often have this issue in the past when testing Texinfo manuals and create Info files in the wrong place on my computer by mistake (until I commented out the @setfilename lines in the files I was testing). > > > 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?
