More of Lua in Celestia?

[don]

Chris,

Is it possible to implement a little bit more of Lua in Celestia? For example...

* The ability to READ files, but not write them?

* Access to some of the "system" info.?

* Other things that would not pose a danger from malicious scripts?

Or can Lua features only be implemented on a "section-wide" basis (ALL of a section of Lua, or NONE of that section)?

[Harry]

Is it possible to implement a little bit more of Lua in Celestia? For example...

* The ability to READ files, but not write them?

It's more work than simply allowing all I/O, but certainly doable. The question is not so much a technical one, but one of how to do it, i.e. I would like to see some agreement about what a script should be allowed to do. Even writing files isn't out of question, if there is a consensus about how to make it safe (like restricting it to one special directory).

* Access to some of the "system" info.?

* Other things that would not pose a danger from malicious scripts?

Can you give some examples of what you are thinking about?

Or can Lua features only be implemented on a "section-wide" basis (ALL of a section of Lua, or NONE of that section)?

Lua provides a I/O library which could easily be activated (AFAIR a one-line change), but it's an all or nothing decision: if you activate it, you allow scripts to read and write everywhere. So if we want a restricted I/O support, we have to do it ourselves Another possibility is to activate this library only for "trusted" scripts, but I don't think the user should have to worry about whether he can trust a script - so I don't think it's a very good idea.

Harald

[don]

Hi Harald,

It's more work than simply allowing all I/O, but certainly doable.

This is good news!

I would like to see some agreement about what a script should be allowed to do. Even writing files isn't out of question, if there is a consensus about how to make it safe (like restricting it to one special directory).

If I remember correctly (which is not always the case), I think it was agreed in the developer's list to add a sub-directory to the celestia directory for scripts. If this actually ever gets done, then adding a sub-directory called "data" or "files" under the scripts directory would make a good place for storing files to be read or written to from within scripts.

* Access to some of the "system" info.?

* Other things that would not pose a danger from malicious scripts?

Can you give some examples of what you are thinking about?

* Current system date/time
* Current window size (height / width)
* Current script font size (height / width)
* Other?

Some of these would obviously require new Celx methods, since they are based on Celestia-specific data. The font/window metrics would be used to implement right-to-left text display (for non-English languages), along with intelligent text wrapping.

[Harry]

I would like to see some agreement about what a script should be allowed to do. Even writing files isn't out of question, if there is a consensus about how to make it safe (like restricting it to one special directory).

If I remember correctly (which is not always the case), I think it was agreed in the developer's list to add a sub-directory to the celestia directory for scripts.

Do you mean the the directory for scripts included in the default Celestia installation?

If this actually ever gets done, then adding a sub-directory called "data" or "files" under the scripts directory would make a good place for storing files to be read or written to from within scripts.

However this makes one directory special, which would lead to problems when upgrading etc, (i.e. the reasons why there is an extra-directory). A directory with a special name, relative to the location of the script would IMHO be better.

* Current system date/time
* Current window size (height / width)
* Current script font size (height / width)
* Other?

Sounds ok, though I would have to check how diffictult it is to get the font-height.

Harald

[don]

To make the entire extras directory "movable" from one install to another, maybe the scripts sub-directory could be placed in the extras directory? Then, having a data or files sub-directory under scripts would insure it got moved by the user.

As for font metrics, check out the following (line 3245 of celestiacore.cpp.)...

Code: Select all

  int emWidth = titleFont->getWidth("M");
  int fontHeight = titleFont->getHeight();
  int x = messageHOffset * emWidth;
  int y = messageVOffset * fontHeight;

Thank you Harald!

[Harry]

To make the entire extras directory "movable" from one install to another, maybe the scripts sub-directory could be placed in the extras directory? Then, having a data or files sub-directory under scripts would insure it got moved by the user.

That would be an improvement, but this still requires the user to copy eventual data-files to this directory when "installing" the script. IMHO this should not be necessary - if the data-dir was relative to the position of the script, it would suffice to extract the script along with the data-dir and the data in it whereever you want, and then simply run it.
If writing should be allowed for scripts, this directory would need to have a very special name, to remove any chance there is a non script-related directory with the same name - and I can still think of security problems with this. The question is, how paranoid do we have to be?

As for font metrics, check out ...

Thanks!

Harald

[don]

That would be an improvement, but this still requires the user to copy eventual data-files to this directory when "installing" the script.

Sorry, I'm not following you.

The directory structure I recommended would follow the currently recommended structure for *all* add-ons...

Code: Select all

celestia
  extras
    extra#1
    extra#2
    scripts
      files

Whenever a new add-on is installed, it is unzipped into the extras directory and all required sub-directories are created automatically, and filled with their contents. The same thing would happen with a script that was distributed with a data file. No "manual" user work is required. I would force all WRITING to take place in this "special" directory, but allow READING from any directory (ie. celestia/data).

[Harry]

Whenever a new add-on is installed, it is unzipped into the extras directory and all required sub-directories are created automatically, and filled with their contents. The same thing would happen with a script that was distributed with a data file. No "manual" user work is required. I would force all WRITING to take place in this "special" directory, but allow READING from any directory (ie. celestia/data).

Maybe we are having the same idea, so I only want to emphasive one point: Is it really necessary for a script to be installed in the extras-directory? I don't think so. I would like to have the possibility to simply extract it wherever I want (say on my Windows-desktop), run it, and then either keep it (maybe move it to the extras-directory) or delete it. This wouldn't be possible if the data-files have to be in the extras directory.

Harald

[selden]

It seems to me to be reasonable to be able to run Lua scripts that are in Celestia's directory tree, but not to require them to be there.

If a Lua script is intended to be used to enhance Celestia, I think it's appropriate to keep that Lua Addon in the Celestia directory tree and for there to be a convention for where such scripts are kept. Remember that you can put a shortcut or softlink pointing to such a script anywhere that's convenient.

If a Lua script is used for general purpose programming but just happens to use the interpreter built into Celestia, then it seems to me that it is reasonable to be able to put that script anywhere on the system.

Another thing to keep in mind is that scripts differ from traditional Addons: Addons that primarily consist of Catalogs get loaded by Celestia when it starts, so Celestia needs to be able to find them easily. Having specific Addon (or Extras) directories where Celestia looks simplifies this. Celestia doesn't need to find and load scripts (Lua or otherwise) when it starts, except perhaps for an initialization script. Rather, the scripts need to be able to find and load Celestia.

There's also the problem that particular scripts require a specific version of Celestia. I think that's a separate issue, though.

[don]

If writing should be allowed for scripts, this directory would need to have a very special name, to remove any chance there is a non script-related directory with the same name - and I can still think of security problems with this.

This is why I suggested a hard-coded output directory (script/files above) for writing to. This should take care of any security issues such as overwriting system files.

The script could read a file from anywhere on the disk. A script file could be located and run from anywhere on the disk.

As is the case with add-ons, if the user decided to use the scripts directory to store their scripts, they would most likely add categorical sub-directories under "scripts".

If it would make more sense, use a directory called "scriptfiles" under the "extras" directory. The idea is to provide a hard-coded directory for Celestia scripts to WRITE data to.

If a Lua script is used for general purpose programming but just happens to use the interpreter built into Celestia,

This won't happen, as it requires Celestia to be run, and the full Lua language is not included in Celestia's implementation, called Celx.

Another thing to keep in mind is that scripts differ from traditional Addons: Addons that primarily consist of Catalogs get loaded by Celestia when it starts, so Celestia needs to be able to find them easily.

If the "extras" directory were called "user_additions", adding a scripts sub-directory then makes more sense. The extras directory is a place for the user to store ALL things they have added to Celestia, which are not included in the base package, for easy management and moving when updating Celestia.

There's also the problem that particular scripts require a specific version of Celestia. I think that's a separate issue, though.

Same thing for add-ons, but this is a different topic.

[Guest]

If a Lua script is used for general purpose programming but just happens to use the interpreter built into Celestia,

This won't happen, as it requires Celestia to be run, and the full Lua language is not included in Celestia's implementation, called Celx.

Sorry, Don, but you yourself have already provided a counter example: a Julian/Gregorian date convertor.

That is an general-purpose non-Celestia application, although it happens to use Celestia's Lua interpreter.

[don]

Guess we consider "general purpose" to mean different things. My date conversion utility requires Celestia to be installed, loaded into memory and running -- in order to run. It cannot be run without first running Celestia. Thus, I would consider this to be a Celestia-dependant application.

"General purpose", to me, would mean no requirements upon another application. In other words, you double-click the script file from within your OS and it runs, without first loading and running another application (aside from an interpreter, if it is required in background).

[selden]

Yup: different definitions.

In this context, I'd consider a "general purpose" (a poor choice of terms) program to be one that could be written equally easily in any language available to you: they just happen to be written in Celestia's Lua.

Other examples would be routines to calculate N! (N Factorial), or Pi to some number of digits, or the first umpteen primes. Or to convert between Equatorial, Eclipitc and Galactic coordinates.

Celestia-specific scripts are those which intentionally change Celestia's viewpoint.

[don]

As I wrote in topic (http://shatters.net/forum/viewtopic.php?t=4878)...

At this point in time, after seeing several things that COULD have been done with Lua, but discovering that they can NOT be done due to Celestia's limited implementation of Lua ... I agree with maxim that the full Lua implementation should be included in Celestia.

THEN ...

Similar to what Internet Explorer does, add one or more entries in the celestia.cfg file, such as those listed by maxim:

- Allow scripts to execute OS commands?
- Allow scripts to execute I/O commands?
- Allow scripts to run other scripts?

With the possible answers being:
* Enable
* Disable
* Prompt

And the default value for each being "Disable".

When Prompt is selected, Celestia would pop-up a warning box when one of the potentially dangerous Lua commands is about to be executed (write a file, run a program, etc.) displaying the command, and asking the user if they want to continue running the script or cancel it.

Is this possible?