On Wed, Sep 23, 2026 at 09:19:09PM +0200, Patrice Dumas wrote: > On Wed, Sep 23, 2026 at 06:24:18PM +0100, Gavin Smith wrote: > > On Wed, Sep 23, 2026 at 11:18:34AM +0200, Patrice Dumas wrote: > > I question whether this behaviour is useful: > > > > If FILE is a directory or ends with a ‘/’ the usual rules are used > > to determine the output file name (namely, use ‘@setfilename’ or > > the input file name) but the files are written to the FILE > > directory. For example, ‘texi2any -o bar/ foo.texi’, with or > > without ‘--no-split’, will write ‘bar/foo.info’, and possibly other > > files, under ‘bar/’. > > > > It seems that -o has two different modes, which would be easily confused > > by users. The one which is the obvious mode is to give the name of the > > output file, or if the output is a directory, to give the name of the output > > directory. The other mode is to give the directory location if > > the output is a file. (The rules for EPUB are different again and specific > > to EPUB.) > > > > Based on the description in the manual, the same invocation of texi2any > > can switch from one mode to another based on what files exist in the > > file system. > > Indeed, I agree that this could be very confusing. However, if the -o > argument ends with a /, the risk of confusion is much less.
I feel like making "-o DIR" behave differently to "-o DIR/" would just be a fiddly and annoying detail for users. They will wonder why the program is not doing what they want if they miss out the / by mistake (or include it by mistake). It's the kind of detail that users will tend to forget about, or they will remember it makes some kind of difference but will forget what the difference is. (The only other command-line program I know about where a trailing / on a directory name means something is rsync, but for that program it means something completely different.)
