-
-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
settings from command line (environment variables) should not be overwritten by configuration file #652
Comments
Yes, to be sure child process get their own set of config and not inerit command line parameters. Having Command line overide the config makes things more complicated to manage. Also, only parameters set in the config section are reset: if s setting doesnt appears in the config section for the program, the command line one will stick
Ah yeah, I need to fix that
Could be done I guess check for XDG first and fall be to HOME if it doesn't exist. |
Could you maybe document the reasoning at the point where the priorities are documented? I think having this documented would be useful so that one understands why box64 does this differently than other software. Thank you! |
I will, but tbh, this was the more practical behavior for my use cases (wich is basicaly debugging games launched through steam for example). |
Ah no, this was not a "the current behaviour breaks this use-case of mine" but instead a "i was working on this code, was confused about what did, read the docs which confirmed that this is how it's supposed to be and then did not understand why because most other software does it the other way round". To close this issue, I suggest a change to the documentation like this: --- a/docs/README.md
+++ b/docs/README.md
@@ -62,8 +62,9 @@ Notes about Box64 configuration
----
Box64 now have configurations files. There are 2 files loaded. `/etc/box4.box64rc` and `~/.box64rc`. Both files have the same syntax, and is basicaly an ini files. Section in square brakets define the process name, and the rest is the env. var. to set. Looke at [Usage](USAGE.md) for detail on what parameters can be put. Box64 comes with a default file that should be installed for better stability. The file in in `system/box64.box64rc` and should be installed to `/etc/box64.box64rc` If, for some reasons, you don't want to install that file here, at least copy it to `~/.box64rc` or some game may not function correctly.
-Note that the priority is: `~/.bashrc` > `/etc/box64.box64rc` > command line
-So, your settings in `~/.bashrc` may override the setting from your command line...
+Note that settings from `~/.box64rc` overwrite settings from `/etc/box64.box64rc` which overwrite settings from the command line (any environment variables you set).
+So if you have added a setting X for an executable Y in `~/.box64rc` then that will override the environment variable X when you run Y from the command line.
+This is to make sure that child processes do not inherit the environment variables you have set for their parent but instead pick up their settings from `~/.box64rc` or `/etc/box4.box64rc`.
----
|
Ah ok. I understand. I can commit your suggested change yes (or you can do a PR if you want) |
Yes, just copypaste my suggestion and change whatever you feel needs changing. No attribution to my name required for such a small change. Thank you! 😄 |
Hi,
while working on #644 I noticed that settings from rc-files overwrite settings given via environment variables. This is unorthodox and makes it harder to use box64. I know no application where configuration file settings overwrite settings given on the command line. The reason that it's usually the other way round is, that configuration files are intended to specify a default for most executions of a program which can then be altered on a case-by-case basis by command line options (or environment variables in case of box64). As it is, if a user wants to change a setting for an individual execution of box64, they have to first change the value in the configuration file, then run box64 and then change the value back to its original value. This could be avoided if box64 would prioritize environment variable settings over configuration file settings.
Is there a strong reason to do it the other way round for box64?
(also, where its says
~/.bashrc
indocs/README.md
, it should probably say~/.box64rc
, no?)(also, instead of a dotfile in the user's HOME, could box64 not instead read a configuration file in an XDG config location like
~/.config/box64/box64rc
?)The text was updated successfully, but these errors were encountered: