Run: Sub Main MsgBox CreateUnoService("com.sun.star.util.PathSubstitution").getSubstituteVariableValue("$(home)") End Sub Output: file:///C:/Users/User/Documents Expected: file:///C:/Users/User ie %HOMEDRIVE%%HOMEPATH% or %USERPROFILE% References: https://docs.microsoft.com/en-us/windows/win32/adschema/a-homedrive https://docs.microsoft.com/en-us/windows/win32/adschema/a-homedirectory https://en.wikipedia.org/wiki/Home_directory#Default_home_directory_per_operating_system
https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1util_1_1PathSubstitution.html $(home) The home directory of the user. Under Unix this would be the home- directory. Under Windows this would be the CSIDL_PERSONAL directory, for example "Documents and Settings\<username>\Documents". See https://docs.microsoft.com/en-us/windows/win32/shell/csidl#CSIDL_PERSONAL - FOLDERID_Documents Description: Version 6.0. The virtual folder that represents the My Documents desktop item. This is equivalent to CSIDL_MYDOCUMENTS. Previous to Version 6.0. The file system directory used to physically store a user's common repository of documents. A typical path is C:\Documents and Settings\username\My Documents. This should be distinguished from the virtual My Documents folder in the namespace. To access that virtual folder, use SHGetFolderLocation, which returns the ITEMIDLIST for the virtual location, or refer to the technique described in Managing the File System. See https://docs.microsoft.com/en-us/windows/win32/shell/csidl#CSIDL_PROFILE Description: Version 5.0. The user's profile folder. A typical path is C:\Users\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. However, if you are creating a new Known Folder the profile root referred to by CSIDL_PROFILE is appropriate. Comments: 1. Description above would equally apply to linux. 2. This is an OS setting and paths should be equivalent for linux and Windows. 3. Path has been interpreted narrowly for documents but needs to be considered from a more general programming use.
The obvious way to get %USERPROFILE% is sTemp=Environ ("USERPROFILE") I agree that use of Environment variables is bad practice with known security weekness: for security, LO should provide an object that provides direct access to the WinAPI or ShellAPI path requests. Does it? But I'm leery about changing a feature of OO that has been around since V1 just because some other feature is needed.
The $(home) documentation and implementation are in sync. Changing it would be an API breakage. NOTABUG.
The relevant css.util.PathSubstitution implementation code for "$(home)" calls osl::Security::getHomeDir (see SubstitutePathVariables::GetHomeVariableValue, framework/source/services/substitutepathvars.cxx), which in turn on Windows calls osl_getHomeDir in sal/osl/w32/security.cxx. Which was changed in <https://git.libreoffice.org/core/+/515d2579d305a6127c6c194319a58eac62437e33%5E!/> "Replace legacy dynamically-loaded functions with statically linked ones" from calling GetSpecialFolder(&ustrSysDir, CSIDL_PERSONAL) to calling GetSpecialFolder(&ustrSysDir, FOLDERID_Documents)
(In reply to Stephan Bergmann from comment #4) > Which was changed in > <https://git.libreoffice.org/core/+/ > 515d2579d305a6127c6c194319a58eac62437e33%5E!/> "Replace legacy > dynamically-loaded functions with statically linked ones" from calling > > GetSpecialFolder(&ustrSysDir, CSIDL_PERSONAL) > > to calling > > GetSpecialFolder(&ustrSysDir, FOLDERID_Documents) ...but which presumably isn't relevant, as the old SHGetSpecialFolderPathW with CSIDL_PERSONAL should be equivalent to the new SHGetKnownFolderPath with FOLDERID_Documents (see <https://learn.microsoft.com/en-us/windows/win32/shell/csidl>) And I'd accidentally overridden the RESOLVED NOTABUG during a mid-air collision.