Looking for feedback or comments on potentially adding a method of registering custom file handlers that the shell can use when attempting to load a file. As it stands now, the shell will only attempt to load a file if it is a .lua file. This proposal is adding a mechanism that would allow for the shell to load any file type provided there is a registered handler for the file type.

The rationale behind this is that it would allow for the shell to load other script types that are not lua. For example, if you wanted to load a moonscript file, you could register a handler for .moon files. The handler would then be responsible for loading the file with the appropriate interpreter. The useful scope would not be limited to script files however. I imagine that it could also be used to register loaders for images, music, videos, etc.

My initial suggestion is to add a new method to the shell api, shell.registerFileHandler(extension, handler). The extension would be the file extension to register the handler for. The handler would be a function that takes a single argument, the path to the file to load. The handler would be responsible for loading the file and returning the resulting program as a lua chunk / function. Then users could register handlers by simply including a startup script in their startup folder that would register any handlers they want. If implemented, this should ideally also work for shell.run to ensure compatibility with other programs, or derivative shells that rely on the base shell api (mbs for example).

Would shebangs (as mentioned in #551) be an alternative?

Shebangs would be good to have for sure. I think that both features might be useful though. Shebangs would be useful for running scripts, but not for loading stricter or binary file types. Another thing that comes to mind is that shebangs are written in the file itself rather than in the shell. This means that you would have to modify the file itself to change the interpreter or program used to run it. It also means that if you have a lot of files that you want to run with the same interpreter, you would have to modify each file individually. This is not a huge issue, but it would be nice to have a way to register a handler globally for a file type. It would also make the experience more transparent to the user. I think this is similar to how the package.loaders mechanism works. It allows you to register custom loaders for modules loaded by require, and then you can load modules with the same syntax as you would load a Lua module. I think it would be nice to have a similar mechanism for loading files from the shell.

Also especially for script types that are non standard (i.e. not in the rom), you might not necessarily know exactly where the interpreter might be located as the script author. Like before, not a huge issue, but if you're distributing a script, it would be nice to be able to register a handler for it without requiring the end user to modify the script itself. As long as they've set up their computer correctly, they should be able to run it transparently.

What do you think?

I assume what we'd want to handle all file extensions when resolving programs (so foo would look for foo, foo.lua, foo.lisp, foo.moon, etc...). I feel a little bit weird about that, but I guess it's kinda what Windows does.

Also especially for script types that are non standard (i.e. not in the rom), you might not necessarily know exactly where the interpreter might be located

Yeah, that's definitely a problem. One could just expect the interpreter to be on the path, which avoids this a little, but definitely not perfect.

@emmachase Would you be happy for me to close this now that your shebang work is merged, or do you still think this is worth considering?

I do think there is some value still in this suggestion, but I also think it introduces more oddities than value, especially after the shebang feature. Happy to close this.