The fwtCLI.py functions should accept relative paths in the same formats as other cli based filesystem utilities, such as cp, ls, mv etc. For example worlds/adventure/images/background.png or ../characters/wizard/token.png. Unlike those filesystem utilities fwtCLI must update the foundry database in addition to preforming the filesystem operations. Foundry database updates require the file paths to be relative to the foundry user data directory.
On windows resolving a relative path based on the current working directory works as expected, but on Unix OSs when getcwd is called in a path element that descend from a symbolically linked directory the path returned is that of the linked directory not path containing the symbolically linked directory.
practically this is what happens:
if /dev/worlds/adventure is symbolically linked to /Data/worlds/adventure then calling getcwd from with a path that descends from /Data/worlds/adventure (say /Data/worlds/adventure/images) will return a path that descends from /dev/worlds/adventure (/dev/worlds/adventure/images).
So in order to support relative paths foundry-world-tools must be able to algorithmically determine the absolute path of files and directories relative to the Foundry user data directory even if those paths don't appear to be decedents of the Foundry user data directory.
nathan-sain
commented
3 years ago
The fwtCLI.py functions should accept relative paths in the same formats as other cli based filesystem utilities, such as cp, ls, mv etc. For example worlds/adventure/images/background.png or ../characters/wizard/token.png. Unlike those filesystem utilities fwtCLI must update the foundry database in addition to preforming the filesystem operations. Foundry database updates require the file paths to be relative to the foundry user data directory.
On windows resolving a relative path based on the current working directory works as expected, but on Unix OSs when getcwd is called in a path element that descend from a symbolically linked directory the path returned is that of the linked directory not path containing the symbolically linked directory.
practically this is what happens: if /dev/worlds/adventure is symbolically linked to /Data/worlds/adventure then calling getcwd from with a path that descends from /Data/worlds/adventure (say /Data/worlds/adventure/images) will return a path that descends from /dev/worlds/adventure (/dev/worlds/adventure/images).
So in order to support relative paths foundry-world-tools must be able to algorithmically determine the absolute path of files and directories relative to the Foundry user data directory even if those paths don't appear to be decedents of the Foundry user data directory.