[SOLVED] Best way to use command line programs with many options and no default config file?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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?
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
# var1 must be integer 1-20 inclusive
# var2 must be mth of yr in Mth form eg Aug
Obviously you can add param validation to the wrapper script for known limitations/combinations as well.
The wrapper then executes a cmd line like
/dir/cmd val1 val2
# Or eg
/dir/cmd param1=val1 param2=val2
/dir/cmd -val1 -val2
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:
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:
# the change here is the :- is now - which will allow you to set a variable to null if not required
# You can use the word source or a .
# If all configs in a certain directory you will need to provide full path
# $1 is the name of the game
/path/to/mame $1 $var1 $var5 $var2 $var3 $var4
3. Calling wrapper:
4. Call to wrapper with a change:
var3= /path/to/wrapper.sh robby
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