wesnoth --userconfig-dir is relative to home

[ProditorMagnus]

Current:
--userconfig-dir arg sets the path of the user config directory to $HOME/<arg> or My Documents\My Games\<arg> for Windows. You can specify also an absolute path outside the $HOME or My Documents\My Games directory. Defaults to $HOME/.config/wesnoth on X11 and to the userdata-dir on other systems.
However, as processed with https://github.com/wesnoth/wesnoth/blob/master/src/wesnoth.cpp#L336 and https://github.com/wesnoth/wesnoth/blob/master/src/filesystem_boost.cpp#L589, it does not call getenv("HOME").

So wesnoth --userdata-dir "wesnoth/userdata_1_12" --userconfig-dir "wesnoth/userdata_1_12" --server "server.wesnoth.org" results in
User configuration directory: wesnoth/userdata_1_12
User data directory: /home/ravana/wesnoth/userdata_1_12

[ProditorMagnus]

Would it be better to make it work as described, or instead change description? Changing description would be something that can be immediately done, but having these two flags behave consistently would be nice.

[Arcanister]

Maybe command line keys which take path should work consistently across all the programs, such as assume path to be relative to current working directory if it starts with anything else than path separator (or disk name if OS uses them), and to be absolute path otherwise?
Such as --userconfig-dir ../wesnoth-1.13-git-version/config assumes that path was relative to current directory and --userconfig-dir /opt/wesnoth/config assumes absolute path.

[CelticMinstrel]

I'd say change the behaviour, though this behaviour is a little weird as @Arcanister points out...

[ProditorMagnus]

--config-dir should have same issue, and additionally it points to userdata-path and userconfig-path, while it should to userdata-dir and userconfig-dir.

[sevu]

Summing up:
--userconfig-dir uses absolute path or _path relative to the current location_, documentation claims differently

--userdata-dir uses absolute path or _path relative to $HOME_
(same for --config-dir, because it's an alias, Ravanas last post should be addressed by now)

Advantages of the first: You could use the options to have wesnoth installed on an USB-stick. I think it's also more like the cmd options of other programmes

Advantage of the second: Seems easier to have the options behave more similar on different platforms (referring to Aranisters comment above)

Both somewhat makes sense, but in any case, _they should have the same behaviour._

[ProditorMagnus]

I support second, with the understanding that ./ syntax can be used for relative to current location.

[jostephd]

The end state I would aim for is some flag that takes a path argument and (if it's relative) interprets it as relative to the current working directory. If someone wants to add a way to specify paths relative to $HOME or to ~/.config or whatever, that can be made possible under some other syntax, but wesnoth --*-dir=foo should create foo under the current working directory.

For compatibility reasons we can't just make the change, we need to either go through a deprecation phase or add the new behavior under a new --option, but we can figure out the details if we agree on the principle that relative paths should be relative to the current working directory unless the user _explicitly_ requests otherwise.

Honestly, I don't understand why there's even a question. Every other program interprets relative paths as relative to the current directory. This has been the convention for half a century.

[CelticMinstrel]

I agree with jostephd - relative paths should always be interpreted relative to the current working directory.

[GregoryLundberg]

"relative to $HOME" has the advantage of having a know point where package maintainers can all agree, we're idiots. Which is better than be accused of being random idiots, I suppose.

/s

[jostephd]

Created https://github.com/wesnoth/wesnoth/pull/4449 for deprecating the relative paths in 1.16. Just adds a deprecation message without other changes.

[jostephd]

4449 has been merged, which deprecates relative paths interpreted relative to $HOME. We can change the meaning of --user-data-dir in 1.17.0 or later.