/g/ - Technology
install openbsd
[Make a Post]It depends on the software. For server software you typically want everything specifiable from the command line and allow an option for specifying what config file to use. If it's more of a utility, then you should treat command line arguments like inputs to a function. A config can store defaults for parameters that will be the same 99% of the time and then the user can configure a flag when calling the program.
>>7639
An alias creates essentially a builtin command to you shell which expands to an actual command. For example a common alias is aliasing `ls -l` to `ll`.
An alias creates essentially a builtin command to you shell which expands to an actual command. For example a common alias is aliasing `ls -l` to `ll`.
Config file is almost always better, unless your program has <5 commands. It's easier to automatically setup a system with config files. You also remove ambiguity (some symbols might not be parsed correctly in command line when doing shell pipping).
>>7632
Command-line arguments, so I don't have to manage 50 different files all in different locations. Any decent program would give you the option to specify parameters with a config file and shell arguments anyway.
Command-line arguments, so I don't have to manage 50 different files all in different locations. Any decent program would give you the option to specify parameters with a config file and shell arguments anyway.
>>7749
He is talking about the way that suckless does configuration. Here is an example for st https://git.suckless.org/st/file/config.def.h.html
It's actually ran through a script to make the .h file, but you should get the idea.
He is talking about the way that suckless does configuration. Here is an example for st https://git.suckless.org/st/file/config.def.h.html
It's actually ran through a script to make the .h file, but you should get the idea.
What do you mean, which one to use? With someone else's tool? I guess use a config if the settings are persistent or use an alias/shell script in case it's a separate thing. If you're writing your own program, don't be a lazy nigger and add support for both if the options are more than 10.
>>7751
>I guess use a config if the settings are persistent or use an alias/shell script in case it's a separate thing.
it's both persistent and separate at the same time
configs/parameters are rarely changed, but need multiple ones of them for different purposes
>If you're writing your own program, don't be a lazy nigger and add support for both if the options are more than 10.
if I add support for both, which one should I use as an user? how to decide?
>I guess use a config if the settings are persistent or use an alias/shell script in case it's a separate thing.
it's both persistent and separate at the same time
configs/parameters are rarely changed, but need multiple ones of them for different purposes
>If you're writing your own program, don't be a lazy nigger and add support for both if the options are more than 10.
if I add support for both, which one should I use as an user? how to decide?
>>7757
>if I add support for both, which one should I use as an user? how to decide?
If a user wants to configure something for a one time thing, then he should use a command line option. If he wants it to persist then he should edit a config file.
>if I add support for both, which one should I use as an user? how to decide?
If a user wants to configure something for a one time thing, then he should use a command line option. If he wants it to persist then he should edit a config file.
>>7762
>If a user wants to configure something for a one time thing, then he should use a command line option. If he wants it to persist then he should edit a config file.
what if user wants it to persist but have multiple configs?
config1, config2, files
but how to run the software with different configs?
>If a user wants to configure something for a one time thing, then he should use a command line option. If he wants it to persist then he should edit a config file.
what if user wants it to persist but have multiple configs?
config1, config2, files
but how to run the software with different configs?
>>7764
Typically you add a command line option for specifying the path of the config that you want to us.
Typically you add a command line option for specifying the path of the config that you want to us.
>if I add support for both, which one should I use as an user? how to decide?
A user chooses to use what is more convenient. Do what aria2 does. It has a path for the main config, but you can also provide it with a --config flag. And there are also flags for every option, obviously.
A user chooses to use what is more convenient. Do what aria2 does. It has a path for the main config, but you can also provide it with a --config flag. And there are also flags for every option, obviously.
Both have their place.
Config files are easier to share, track through git, and persist. They should be for settings that don't need to be change often, such as per-machine configuration. If there is a very large number of options, a config file is the only sane solution, as multiline CLI commands would quickly become unwieldy (unless you make a shell script).
When running a program many times in quick succession, such as trying it on different input files to see what they will do, it would not be practical to open up the config in a text editor every time. Also you might forget what configs you put in at your last run. So for options that need to be changed often, or to be ephemeral, arguments are better.
Ironically my IDE makes it more work to change arguments so I tend towards config files in my own programs.
Config files are easier to share, track through git, and persist. They should be for settings that don't need to be change often, such as per-machine configuration. If there is a very large number of options, a config file is the only sane solution, as multiline CLI commands would quickly become unwieldy (unless you make a shell script).
When running a program many times in quick succession, such as trying it on different input files to see what they will do, it would not be practical to open up the config in a text editor every time. Also you might forget what configs you put in at your last run. So for options that need to be changed often, or to be ephemeral, arguments are better.
Ironically my IDE makes it more work to change arguments so I tend towards config files in my own programs.
>>7632
they're literally both shit
they're literally both shit
[Catalog][Overboard][Update]
[Reply]0 files, 19 replies
vs
command line params as config
which one to use and why
the second has the advantage that you can have single executable but multiple files that run it with different params. you could achieve similar thing with config files, if config file path was passed as command line parameter. but what's the point of separate config file then?
config file could be more comfortable if you have really big config with comments and multi line stuff
inb4 GUI. you can have GUI for configuration both if you use config files or command line params
but config file and command line params are needed anyway if you want to automate or call from another app
also designing and developing GUI is often overkill for small shit app