I wish to construct platform independent file paths within a template for a theme used by users across multiple operating systems. For example, a path would need to be constructed as /x/y/z on *nix or \x\y\z on Windows.
I don’t believe that Hugo’s Path template functionality currently supports constructing platform independent file paths.
Therefore, what would be the optimal workaround? I’m thinking either check for an OS dependent environment variable or grab the directory separator by calling one of Hugo’s functions that provides a file path as output.
Generally, having access to a template variable containing the OS string and/or directory separator (/ or \) would be helpful to enable a number of applications.
It works fine on *nix hosts (which is obviously pretty much all hosts) but currently the relationship manager breaks on Windows due to the hard coded directory separator that is concatenated to form paths to content files.
@bep to further clarify, the code linked above is attempting to determine if a page is a page bundle, and if so, get the directory name of the page bundle. Currently, I believe Hugo can only directly provide the full dir path (.File.Dir). It would be nice to have something like .File.PageBundleName as .File.LogicalName will just return index when run within a page bundle.
Alternatively, if OS or directory separator can be provided in a Hugo template var, this would enable the theme designer to compute the Page Bundle Name.
This work around is based on certain assumptions and is not that elegant, so it would still be nice to have one or more of the 3 above suggestions built into Hugo.
The 3 suggestions concern implementing one or more of:
a template var for OS string (giving something like Windows, Mac, or Linux)
a var for file system dir separator (/ or \) to enable construction of file paths
I wasn’t aware of .File.ContentBaseName as it’s not in the docs - I assume it was added fairly recently. It looks like .File.ContentBaseName performs exactly what I was after by obtaining the content name irrespective of whether the page is a bundle or not
Path.dir and associated functions also look really handy as they convert the path to *nix form as opposed to .Dir which would require OS dependent processing in this scenario.