From mike at mikemccombe.co.uk Sun Oct 4 17:28:48 2026 From: mike at mikemccombe.co.uk (mike at mikemccombe.co.uk) Date: Sun, 4 Oct 2026 16:28:48 +0100 Subject: [Therion] Filename resolution for source and input is inconsistent with documented Therion syntax Message-ID: <00c201dd5415$0d6879a0$28396ce0$@mikemccombe.co.uk> In the description of the "input" statement, The Therion Book states: "Default extension is .th and may be omitted." I understand this to mean that: "input bigcave" is equivalent to: "input bigcave.th" rather than meaning that an actual extensionless file named "bigcave" is also a valid Therion source. Both "input" and "source" ultimately use thinput to open files. The filename-resolution logic appears to try an extensionless pathname before applying the configured extensions. Thus, given: "input bigcave" Therion effectively tries: bigcave bigcave.th bigcave.th2 stopping at the first pathname it can open. This causes a platform-dependent failure if a directory called "bigcave" exists alongside "bigcave.th". Under Windows, attempting to open the directory as an input stream fails, so Therion continues and successfully opens "bigcave.th". Under Linux, opening the directory as an input stream succeeds. Therion therefore accepts the directory as its source and subsequently attempts to read it as a text file. The stream enters a failure state, which Therion reports with the misleading fatal error: "Line too long" The same problem occurs with "source". Minimal reproduction: Create a directory containing: thconfig bigcave.th bigcave/ (an empty directory) with thconfig containing: "source bigcave" and bigcave.th containing valid Therion source. On Linux this fails with "line too long". Any of the following makes it work: * Change the configuration to "source bigcave.th". * Remove or rename the "bigcave" directory. * Compile the same ambiguous project under Windows. This suggests that the underlying problem is that "the .th extension may be omitted" has been implemented as "first try opening the extensionless pathname" rather than "if the extension is omitted, use the default .th extension." There is a related issue with using the same generic filename-resolution mechanism for both "source" and "input". I believe the intended semantics are: input bigcave -> bigcave.th input bigcave.th -> bigcave.th input bigcave.th2 -> bigcave.th2 source bigcave -> bigcave.th source bigcave.th -> bigcave.th source bigcave.th2 -> invalid An explicitly specified .th2 file is therefore a valid target for "input", but that does not make .th2 an alternative default extension when the extension is omitted. Similarly, an actual extensionless filesystem object is not a valid interpretation of either statement. In other words, thinput appears to test filesystem objects that are not valid interpretations of the Therion statement that invoked it. Resolving the filename according to the semantics of "source" or "input" before attempting to open it would also remove the Windows/Linux difference and prevent a directory from being mistaken for a Therion source file. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: