It’s safe to include dash and underscore. (Which people want for multi-word filenames.) Space should be safe as long as the interpreter system doesn’t include any badly-written shell scripts.
(I am currently tweaking RemGlk to sanitize filenames in the fileref_create_by_prompt() case. It already does in the fileref_create_by_name() case, but I assumed that a user typing a filename could do whatever they wanted. True for many use cases, but not all!)
“.” can be bad because of it’s use to escape the current directory unless blocked. Yes, it’s also used for extensions, but if we’re talking about auto-saved files an extension seems kind of unimportant.
Yes dash and underscore are safe and I almost listed them too, but it seemed safer to just say “no” to punctuation altogether. Spaces are problematic because of exactly what you just said - it is super-easy to write a naive shell script with that kind of problem.
I mean these names are just “suggested” by the game anyway. They are not enforced unless you are also using the ability to save unprompted, in which case what does the exact name even matter?
I’m pretty sure anybody writing a shell script in 2025 has been writing shell scripts for twenty years, though. And the number of people writing shell scripts to handle IF interpreter data files might be, like, six. My comment above was mostly a joke.
Although not required by the Z-Machine spec, a lot of interpreters would probably base their rules on the Glk spec’s sanitising rules:
The library should take the given filename argument, and delete any characters illegal for a filename. This will include all of the following characters (and more, if the OS requires it): slash, backslash, angle brackets (less-than and greater-than), colon, double-quote, pipe (vertical bar), question-mark, asterisk. The library should also truncate the argument at the first period (delete the first period and any following characters). If the result is the empty string, change it to the string “null”.
I’m not sure about this. I probably reported issues with it previously as my cheap-mode GlkOte-term did no checking at all. But that was more that when prompting for a file to read it should’ve checked it existed or returned null. When prompting to write a file it should allow for any OS allowed filename.
I’m just suggesting something similar ought to be in the z-spec…not everyone wants or needs to use Glk.
That’s not true, I’ve only been writing them for… checks calendar … nevermind.
I wound up making it an option. The default behavior is the existing behavior: the user can type any filename, including absolute or relative paths.
With -onlyfiledir, RemGlk discards slashes and backslashes from the prompted filename. So the file will always be saved in the working directory. (Or a specified -filedir DIR.)
This is for the Discord bot case, where the user is on Discord but the interpreter is running on my server. No fair telling the interpreter to save a file in /home/zarf/.ssh!
I’m looking at adding support for Parchment support for Bocfel’s zterp_os_aux_file function. Which storyfiles can I test with that use the prompt option?
I’ll send you a file privately, as it’s part of a WIP. Thanks!
I’ve updated Bocfel and now Parchment to include support for no-prompt file opens! Get at it all you Z-Code hackers!