This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
thecrimulo's profile picture

File extension dilemma

Started by thecrimulo, 19 October 2016 - 05:25 PM
thecrimulo #1
Posted 19 October 2016 - 07:25 PM
Hi there.
Yesterday, in a conversation in Silica's gitter, I wanted my WIP OS to use custom file extensions, .l for libraries, .i for system images…
I don't want the system to be extension-dependent, on its metadata, it will have its custom MIME-like type. The problem comes when in the chat, I was told that I should use .lua extensions on every lua code file, for the people that use an external editor and doesn't want to link those extensions to highlight as Lua, just making it work out of the box. I don't want to have .lua extensions for everything, because I don't want the shell to run system images (that are ran on boot and will probably bug if ran again), libraries (that are only meant to be called and not ran from shells), and types that identify those files will work. I evidently want people to modify the source as they want, because its open source, but not having a .lua extension makes it tedious to change syntax. So the dilemma is: I don't want .lua extensions in the OS (when in ComputerCraft, and the user evidently can make .lua files and be recognized as Lua source, just not in my code) but I want people to edit my source and they want .lua extensions.

What do I do? Should I develop my own types for the OS only or should I make all files use a .lua extension and find other way of identifying those?
Lupus590 #2
Posted 19 October 2016 - 08:02 PM
I would use a multi-extension system, with your OS using the first one to identify the file with the last being used by the real OS (Windows - Unix-like OSs read the file to work out how to open it).
Example file name with all extentions: myLib.l.lua

this may help: http://www.computerc...-extension-api/

alternatively you could use the metadata API: http://www.computerc...p?/topic/18646-
there is an implementation here: https://github.com/lyqyd/metadata
Edited on 19 October 2016 - 06:08 PM
Admicos #3
Posted 19 October 2016 - 08:02 PM
There are some "standards" here so you might want to use them. (Meaning, use .lua)
Edited on 19 October 2016 - 06:03 PM
thecrimulo #4
Posted 19 October 2016 - 10:55 PM
I would use a multi-extension system, with your OS using the first one to identify the file with the last being used by the real OS (Windows - Unix-like OSs read the file to work out how to open it).
Example file name with all extentions: myLib.l.lua

this may help: http://www.computerc...-extension-api/

alternatively you could use the metadata API: http://www.computerc...p?/topic/18646-
there is an implementation here: https://github.com/lyqyd/metadata

I like the idea of using metadata, tho I think I am going to do it myself when I implement the FS API modification.
Maybe I can strip the last extension (.lua) and make it not needed on any function, so it virtually doesnt exist.

There are some "standards" here so you might want to use them. (Meaning, use .lua)

Probably, I will use the standards on the MIME types, and make another tag for whether its library, image, system image, or anything else.
H4X0RZ #5
Posted 20 October 2016 - 12:01 AM
One, more advanced, idea is to make a custom FS implementation which reads metadata from all the files (probably either stored in the header, or, according to the metadata standard, in a mirrored folder), and allows you to set a custom extension using metadata. You could have a file called system-image.lua, but the metadata could look like this:

{
  fileName = "system",
  fileExtension = "i"
}
and your custom FS would magically make the file system-image.lua appear to be system.i to the computer, even though the actual file never changed it's name.

I have some "bootstrap" code which might help you with implementing a custom FS. This is a lib from my "OS" (Helium). You would just have to implement some middleware which reads the metadata from the file and stores it in the node. Then add a custom function to BaseFS (or your FS implementation. Could be RamFS too) which returns the metadata of a file.
Edited on 19 October 2016 - 10:04 PM