ini-path argument using relative path, non-critical

[andy_5995]

This applies to Rev: 5354.60f7eb5

The --ini-path argument seems to be broken for me. Here's what happens when I use the absolute path:

andy@asus:~/megaglest-git/megaglest-source/mk/linux$ ./megaglest --headless-server-mode --ini-path=/home/andy/.megaglest-git/
megaglest v3.12-dev
Compiled using: GNUC: 40902 platform: Linux endianness: little
GIT: [Rev: 5354.60f7eb5] - using STREFLOP [SSE] - [no-denormals]
terminate called after throwing an instance of 'Shared::Platform::megaglest_runtime_error'
  what():  File NOT FOUND, can't open file: [/home/andy/megaglest-git/megaglest-source/mk/linux//home/andy/.megaglest-git/glest.ini]

Also, shouldn't mg be looking for glestuser.ini, and not glest.ini?

[filux]

Basically we need here relative path, it is much more universal way. Same parameter will work for you and for someone else in the same situation.

There is nothing wrong in having possibility to set it as "absolute or relative" but conversion "relative" > "absolute" is imo a wrong idea.

In the glestuser.ini you will not find all the settings, just only few "modified by user" and it is not enough for MG.

[andy_5995]

Thank you, filux! This can be closed then.

[Omega]

Eh, there's no reason to be constrained to relative paths. That makes no sense. It's a command line flag, so it doesn't matter if it works for other people.

This is probably due to concatenating a path somewhere instead of letting the OS work its magic. While I couldn't find the code where this occurs in a timely fashion (and can't be bothered booting up a debugger this late at night), I did note that the INI path applies what MG refers to as "tags" but would more properly be pictured as the environmental variables of a shell. Eg, you can do %%APPDATA%%/foo and MG will replace that with the appropriate path. Those only make sense for absolute paths.

Therefore, the current functionality seems to be unintended.

[filux]

"Eh" Ehhhh
Hehe funny and sad at once. @Omega Do you realize that most part of your post was a pure trolling?
If you can talk like this all the time then probably BSD community may welcome you with open hands  .

Eh, there's no reason to be constrained to relative paths. That makes no sense...

Oh because just because? "Good" beginning, no comment.

...It's a command line flag, so it doesn't matter if it works for other people...%%APPDATA%%...

Just ridiculous, completely opposite, Perfect is when:
- it work for you also when you will move whole main game directory to the other place,
- it may work for other players in the same way when you need this (when you need, so absolute paths in other cases are allowed),
- it is easy to use, proposition of "%%APPDATA%%" is pitiful, how to document usage of this and where? if in the --help then most likely it will be too long, if not in the --help then it is not enough easy accessible,
- it will work on every OS and every command line env cause MG is cross platform, using characters like "%" in the command line is just asking for trouble.

...This is probably due to concatenating a path somewhere instead of letting the OS work its magic...%%APPDATA%%...

What magic?  On which OS? (cross-platform!) This one which your variable seems to suggests, where even simple usage of %programfiles% may return unexpected results? or this magic related with sending personal data to mICROSOFT? 
When you wanna cross-platform support then you need to avoid as much "unexpected magic" as it is possible.

...Therefore, the current functionality seems to be unintended.

Hmm In my opinion this functionality was intended and I am pretty sure there was a time when was widely used (some old svn times). Since softcoder introduced glest-dev.ini is probably much less used, but for sure is still used sometimes.
Some months back there was a bug related with paths and every "git user" had to use for ~ 1-2 days --ini-path=./ --data-path=./ to even launch game (relative? relative, simple? simple) and even now our headless servers 3.11.1 have relative path to ini in the configuration.

Did you ever tried to help someone or write a documentation related with absolute paths?
Try to write something like this: "if ... then Please use --ini-path=<path_to_the_file>" and you have a guarantee to get some % responses like this does not work, I see an error: '<path_to_the_file> not found' and those will be from just normal avg users.
Everywhere when you can use relative path you should do this.

Again

...There is nothing wrong in having possibility to set it as "absolute or relative" but conversion "relative" > "absolute" is imo a wrong idea...

How to do this? If we will assume absolute path as default (maybe less confusing). Example:

Code: [Select]

--ini-path=/home/andy/.megaglest-git/mk/linux/
--ini-path=rel,./ Easy to document, easy to remember, easy to use.

... and I probably finished with this topic because I have a feeling that I am feeding ...

[andy_5995]

How to do this? If we will assume absolute path as default (maybe less confusing). Example:

Code: [Select]

--ini-path=/home/andy/.megaglest-git/mk/linux/
--ini-path=rel,./ Easy to document, easy to remember, easy to use.

... and I probably finished with this topic because I have a feeling that I am feeding ...

For absolute, I was thinking something like

Code: [Select]

--ini-path=~/.megaglest-git
But I was looking for a way to specify a different config directory, not simply use a different ini, so I don't really feel a need to discuss this further. Thanks for the replies, gentlemen.

As a matter of opinion, I am simply used to being able to use relative or absolute. Interesting discussion, though some of it was lost on me. I've done very little coding in the last three years, and I never became an expert.

[Omega]

Oh because just because? "Good" beginning, no comment.

Because pretty much every place that accepts relative paths will also accept an absolute path. There's no reason to avoid the norms of most software. In fact, I've never used a program that accepts relative paths and does not accept absolute paths.

- it work for you also when you will move whole main game directory to the other place,

Obviously you wouldn't use an absolute path then! I'm not here to debate the merits of relative paths. I'm a programmer; I know full well their uses. But I also know that absolute paths do occassionally have valid purposes.

- it may work for other players in the same way when you need this (when you need, so absolute paths in other cases are allowed),

But again, that doesn't matter because typically one wouldn't share just any command line argument. Command line arguments are largely to allow you to tweak how the program runs and may not be relevant to others. In this particular case, you simply wouldn't share the command line argument. But all that said, absolute paths can absolutely work for other people. Surely you've executed things like vim ~/.vimrc? I can share that around and anyone who has vim on a *nix system can use it.

- it is easy to use, proposition of "%%APPDATA%%" is pitiful, how to document usage of this and where? if in the --help then most likely it will be too long, if not in the --help then it is not enough easy accessible,

I used %%APPDATA%% as an example of MG replacing variables with absolute paths to show that this is clearly unexpected behavior (since you can't use said variables if only relative paths are allowed). The poor documentation of said variables is off topic. Code tells a lot about the intentions. However, a better example of something that users would actually do is ~/megaglest_shit or %appdata%/customMG. Both of those include variables that are swapped by the OS before the data is even sent to the application (by the shell).

- it will work on every OS and every command line env cause MG is cross platform, using characters like "%" in the command line is just asking for trouble.

Again, there's no need for command line arguments to be cross platform. I mean, heck, Windows and OS X are case insensitive, so you can already create command line arguments that are Windows only. To lazy to check, but pretty sure you'd be able to use backslashes in the path, too. Windows allows that for relative paths, but for Linux, it's just a regular character in a filename.

What magic?  On which OS? (cross-platform!) This one which your variable seems to suggests, where even simple usage of %programfiles% may return unexpected results? or this magic related with sending personal data to mICROSOFT? 
When you wanna cross-platform support then you need to avoid as much "unexpected magic" as it is possible.

By "magic", I was referring to the fact that all modern OSes retain a working directory for which relative paths are based against. Usually this is the working directory of the terminal which you use to launch MG, but shortcuts can usually specify their own working directory. And I dunno why you're bringing up sending personal data to Microsoft. That seems very off topic here and makes me question if you're just trolling me here.

Some months back there was a bug related with paths and every "git user" had to use for ~ 1-2 days --ini-path=./ --data-path=./ to even launch game (relative? relative, simple? simple) and even now our headless servers 3.11.1 have relative path to ini in the configuration.

I'm not sure why you think the fact that a bunch of people use relative paths is a good reason not to support absolute paths.

Did you ever tried to help someone or write a documentation related with absolute paths?
Try to write something like this: "if ... then Please use --ini-path=<path_to_the_file>" and you have a guarantee to get some % responses like this does not work, I see an error: '<path_to_the_file> not found' and those will be from just normal avg users.

Yes I have. I help with the annual Unix Bootcamp at my university, which caters to people who have never used a terminal in their life. But the reality is that anyone who's dumb enough to make the mistake you showed is not someone who should be using command line arguments. They're not exactly hard to use, but require the ability to read and understand what the arguments are. When creating documentation for intelligent people, I've never had issues with simply using the placeholder <path> and stating whether or not it must be absolute (there's a small number of cases where relative paths would be too confusing due to the lack of an obvious path which they'd be relative from).

At any rate, here's a recent example of why you'd use absolute paths. It's a per user thing and Tomreyn is clearly banking on the reader having the intelligence to change the paths to whatever value they are using. You could use relative paths here, but it's more confusing because you'd have to figure out the point that we're relative to. Absolute paths are often superior for personal usage because they remove that source of confusion -- you always know where the path is pointing.

In the *nix community, absolute paths are used all the flipping time, usually relative to the home directory (using the nifty ~ variable -- the Windows equivalent is a bit more verbose: %userprofile%, but PowerShell allows the use of ~).