In Sphere, ~/... is a path which is relative to the game directory.  TurboSphere adds #~/... for the system directory.  Are there any other escapes I should know about?  I will add them to minisphere for the 1.1 release.

I don't know the answers, but there are a couple things that should probably be checked if you want to really be compatible:

• What does `./` do?


• What does `/path` do?


• How much canonization happens? Would ~/../[game folder name]/ work?

I don't strongly escape paths in TurboSphere although I do fully canonize them with respect to the TurboSphere directory for relative paths and the root on Unix and drive path on Windows and the pool on Solaris. The level of canonization is important. Without that, this would fail if there is no `other` directory:

Code: (JavaScript) [Select]

var image_file = new RawFile("../images/raw.tga");

But I also do not sandbox the engine with regards to the FS. Either the user knows the absolute path, or you it's relative and you would have to walk the FS by hand. Will you sandbox the FS?

Currently it's sandboxed insomuch as absolute paths are rejected (get_asset_path() returns NULL).  Tricks with ../ can bypass it though, as I was too lazy to prevent that.  Of course honestly, I only sandboxed it at all because that's what Sphere does, I suppose it wouldn't hurt to open it up.  Nobody's going to be programming viruses in Sphere.

I do canonize paths, yes.  Also ../images/filename will work even if the "other" directory doesn't exist because Allegro's path routines don't care whether the dir exists or not, just that it's a well-formed path.

Edit: no it won't, ignore me, I'm an idiot.  You can't blindly collapse double-dots in paths because one of the components could be a symlink.  So a relative upstream path from a nonexistent directory is indeed broken--UNLESS the semantics of the API in question include a clause to create the directory--for example, OpenLog(), and OpenRawFile() in write mode.

I don't know the answers, but there are a couple things that should probably be checked if you want to really be compatible

So I did a few tests.

Code: (javascript) [Select]

function game()
{
    var sound = LoadSound('<fill in path>/Munch.wav')
    sound.play(true);
    while (true) FlipScreen();
}

• What does `./` do?
  Nothing. Specifically, prefixing a filename with a dot-slash is the same as no prefix at all.  This means the engine either A) treats the default directory for the requested resource as the current directory, or B) Canonizes the filename into an absolute path and opens that.  minisphere does the latter, and from what I saw in the Sphere source, I believe it does the former.  SSFML, however, is an oddball: No error, but no sound either.
  
  


• What does `/path` do?
  Sphere 1.5 - "Invalid filename".  This is a sandbox violation so Sphere will have none of it.  minisphere errors out as well as the filename fails the relative-path requirement.  SSFML again provides to be an odd duck here: It loads the file from <game_dir>/sounds!
  
  


• How much canonization happens? Would ~/../[game folder name]/ work?
  In Sphere 1.5, that would be a resounding "No".  Invalid filename again--it treats it as a sandbox violation.  minisphere and SSFML both play the sound.
  
  


• Bonus test: ../../../../../../Munch.wav (taking the long way to root)
  Sphere 1.5: Sandbox violation again. I have to say I'm impressed, this thing is built like Fort Knox!  minisphere: Sound plays.  SSFML: Sound plays.
  
  


• Bonus test #2: Symlink to external directory
  And the mighty Sphere 1.5 falls!  The sound plays; even its sandbox isn't enough to deal with this level of shenanigans.  Naturally, minisphere and SSFML both succeed in playing the sound as well.