Best way to use command line programs with many options and no default config file?
 

I want to know what is the best, fastest, most efficient way of dealing with command line only programs that have many, many options. I must be able to easily modify the options or be able to store them as defaults.

As many of you know, Linux is not big on GUIs, but very big on command line. This is fine to some extent, but gets cumbersome as some of these command line programs can have upwards of 100s of options. I would like to know the best way in dealing with such programs that contain many different options but offer no default config file (.ini, etc) to easily configure them.

I know that I could use a script (or alias) and type in the command with a set of options, but this only works for commands that I wish to repeat frequently.

What would I do if I wanted to use a program with, say, 50 options, variably? I would have set the options manually every time I wanted to start the program. Now, I'm a decent typist, but doing this would get old fast. Surely there is a better way of doing this?

It's very hard to think of a scenario in which this would actually happen; where you would need to run a program with 50+ options that are completely different each time you run it.

As you say, a script or alias is the most logical solution to the problem. If there really is some case where you would need 50 variable command line switches, I can't think of any way to gracefully handle that other than writing some kind of wrapper script/tool that intelligently adjusts the various options depending on whatever criteria would require you to be changing them so often in the first place.

Okay well what about a program that contains no configuration file, but has many options? What would be the best way to build such a file from scratch? That way I could use it as a default, but then override any of the defaults with just a couple of options on the command line. At least that way I would only have to use the options I want to change instead of of typing all of them every time.

Using a script for the defaults wouldn't work because there would be no way to dynamically override the defaults on the command line.

What you would do is write a wrapper in eg Perl that reads a cfg file (of eg 50 params) file to get default values for target prog to be called with.
You can then add cli interface or use cmd params to wrapper to alter just a few/all ie target will be called with default values unless overridden by wrapper.
I all depends how many param values you are likely to vary on a given run; for small num, pass as cmd line params to wrapper, to change a lot, edit the cfg file.
If you have a few combos that get used regularly eg 50 total params, but only a few combo variations, create cfg files (one for each variation) and call the wrapper passing the name of the reqd cfg file.

The advantage of a wrapper is you can get it to check for invalid combos and/or too many/not enough params, or reqd parma(s) missing... basically param validation.

It depends on why you are doing this; maybe you can get the wrapper to figure out what combo to use, given the circumstances in which its called.

Do you have a specific example/reason for this?

You could do the same as the above in bash and source in the appropriate defaults and even use parameter substitution
if you need to only change a couple.

I would agree with Chris that you need to provide an example of a likely scenario?

Well lets take MAME for example. To run a single game, without default options or a config file, on the command line it might look something like:

From http://mamedev.org/source/docs/config.txt.html

mame <gamename> [options]

Basically, the beginning commands are defining all the default directories <path> in which to find files related to that option. The next set of options specify things such as brightness level, contrast, gamma, video options, sound options and others. There could be many more options if needed and the defaults are not adequate.

So typing out all those commands every single time to run a game would be cumbersome. Writing a script would not help because each game would require different options and I may want to change existing options on the fly.

The Sw is not psychic, you basically have 2 options

1. provide all params on cmd line each time (hard option)

2. use a wrapper script with cfg file
2a) allow wrapper to override defaults in cfg file by supplying new values on cmd line
2b) as above, but get wrapper to ask interactively per param ; possible if you have a 'no more changes' answer as well
2c) edit cfg file before calling wrapper

The advantage of 2 is that you can also get wrapper script to save each new set of param values in a named cfg file eg mylowspec.cfg, myhighspec,cfg etc.

You are unlikely to require a unique combo each time you play, so after while you'll have a separate named cfg file for each likely scenario.

Okay well how would I construct a cfg file then? I'm only aware of things like .ini files which have special syntax and obviously wouldn't work if the program didn't already support it. How would I create a cfg file for a program that doesn't support anything natively?

Are we just using mame as an example as it has a lot of options, because it seems it has the ability to create
a config file:

I'm just using Mame as an example. I know it can create a config file. I'm interested in programs that can't create one but have many options.

The generic cfg file would be read by the wrapper script, then a cmd line would be generated by the wrapper, which then calls the actual prog, passing the params as reqd.
The cfg file can be any format you like; the most simple one is
The ones I create in my work also allow for blank lines and comment lines ie those beginning with '#' char.
This enables you to leave reminders to yourself about eg valid values (ranges) for each var eg
etc
Obviously you can add param validation to the wrapper script for known limitations/combinations as well.

The wrapper then executes a cmd line like
or whatever format the actual cmd requires.

Further to chrism01's post, you can take it a step further to where you were worried what if you need to change
a couple of the items but leave the rest by setting up the config file (assuming bash) to look like:
Then when you execute the wrapper you can say:

Okay I'm just a little bit lost. Can we just take a simple example like:


mame robby -video opengl -nohwstretch -switchres -triplebuffer

So mame is the program name, robby is the game name, and it is modified by four options. Now for a cfg file, would it look something like this (using Grail's modifications)?

#robby.cfg

var1=${var1:-"video opengl"}
var2=${var2:-nohwstretch}
var3=${var3:-switchres}
var4=${var4:-triplebuffer}

Now the command would be:

/home/user/mame $@ $var1 $var2 $var3 $var4

What would the wrapper script look like exactly? I'm still confused about that.

Ok ... so a few slight changes required for the cfg file. Firstly, you need to remember to include the entire string,
which may not have been clear as the ':-' is actually a construct and not the leading dash for each switch.

Secondly, I would probably set variables for items you pass to switches as well so they can also be changed, ie. 'opengl'

Lastly (and this is an error on my behalf), I assume there will be instances where you would like
to remove / blank certain options, ie. remove -switchres as an option.

SO ... this is a starting suggestion:

1. robby.cfg
2. wrapper.sh
3. Calling wrapper:
4. Call to wrapper with a change:
This will remove the option to use the switch -switchres

Now you may need some tweaks and quoting if white space is an issue anywhere, but have a play and see how you go :)

Alright that seems close to what I want to do.

What if I want to substitute an option instead of removing it entirely? For example, replacing "nohwstretch" with "hwstretch" and "triplebuffer" with "doublebuffer".

So how would the actual command change?

Would that work?