get*Directory output

Issue #488 wontfix
created an issue

On Windows, love.filesystem.getUserDirectory() returns

C:\Documents and Settings\User\

instead of the expected

C:/Documents and Settings/User

On Ubuntu, love.filesystem.getAppdataDirectory() returns


instead of the expected


love.filesystem.getSaveDirectory() returns


instead of the expected


and love.filesystem.getUserDirectory returns


instead of the expected


Comments (19)

  1. Seppi

    Firstly, I agree that the getXDirectory functions should either have or not have the trailing forwardslash for each platform, but not a combination of both. Also, the double-forward slashes seem extraneous.

    Personalty, I have found that this is an issue with Lua, and would be nice if this could be resolved in a more cross-platform manner through love.

    The os.getenv is one of the few ways to figure out what OS one is running; here is a quick snippet from one of my libs.

    -- WIN
    if os.getenv("APPDATA") then
      sys.dir = os.getenv("APPDATA").."\\vapor\\"
      sys.mkdir = "mkdir "
    -- *NIX
    if os.getenv("HOME") then
      sys.dir = os.getenv("HOME").."/.vapor/"
      sys.mkdir = "mkdir -p "
    if not sys.dir then
      error("Unable to determine system save location!")

    What might be an excellent solution is to gut out the file system within love, and implement the LuaFileSystem or at least supplement love with it, but this again adds yet another dependency when building love. But considering we use socket2, it might not be too bothersome.

  2. Bart van Strien

    I see nothing wrong with these, they are all perfectly valid, and the love source itself inserts some extra slashes on linux because they can be influenced by environment variables, and this makes sure it always works.

  3. hahawoo reporter

    I expected these things because of the inconsistency with back and forward slashes on Windows, the extra slashes on Linux, and the inconsistency with trailing slashes.

    If all of these paths are valid however, I guess it's not a problem, and if a lover wanted consistent-looking paths I'd assume they could use string manipulation.

  4. phoniz

    Wondering why this is a wont fix? The paths returned aren't valid.

    Looking at the code, it might be helpful to have a platform agnostic path_join function

  5. phoniz

    But I can't open this directory /Users/phoniz//Library/Application Support/LOVE/lamegame and it is returned by love.filesystem.getSaveDirectory()

  6. Bart van Strien

    Then whatever you're using to verify this is simply wrong. I just looked this up, and this behaviour is specified and allowed in the Single Unix Specification that is followed by OSX (and linux too, though that's not relevant).

  7. Log in to comment