LQ Articles DiscussionThis forum is for the discussion of content posted to the Articles and Editorials section.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I use bash scripts to do all sorts of things, both in my spare time and for my job, and many of them require creating and reading a configuration file or parsing some options or both.
I used to end up writing very similar code over and over again and dealing with creating config files, parsing options and usage message used to take up a big part in the script. I wanted to do something about this to make my life simpler and minimize the amount of code I'd need to write for dealing with such issues and possibly stop rewriting each time nearly the same thing.
I'm sorry, but I need to say the code you presented is inefficient. You need to eliminate $( .. ), because that will invoke a new shell and usually can be solved without that (which will need less resources, run faster...)
Yes surely but the article is on minimizing code not making it more efficient. It's focus is on reducing the amount of code necessary to deal with input flags/parameters and configuration file creation.
I'll see if I can review the code so that it's not a bad example of bash coding ... can I edit my article ?
Help me find the contents of a variable whose name is in another variable ... I know what I did is a mess but I still can't think of an alternative.
probably there is an edit button, but actually you can post an improved version too.
For posts there is but I can't find it for article, I wanted to avoid rewriting it just make the current version better.
But if it's not possible I guess a rewrite will be scheduled.
You need to eliminate $( .. ), because that will invoke a new shell ...
No $(command) and/or `command` is command substitution and does not invoke a shell unless the command is a shell.
It's the plain ( list ) that invokes a subshell to run the list.
Ok but still you have a point: there are some places where I can do without command substitution and I can declare som variables as integer and do without some of the ((expression)). It will be an exercise for me to write cleaner bash scripts
To my understanding, which may be wrong, $(command) forks the command so if it's a shell it will run a subshell if it's an executable it will execute the command obviously in another process in any case.
$(command) and `command` do the same thing I just prefer the newer $(command) syntax.
As I said before this not about optimizing code for performance but all about minimizing the amount of code necessary to deal with scripts with several options and configuration parameters.
Although I appreciate comments regarding attempting to get petter performance I do thing that they're missing the whole point of the article.
In any case a reedit or improved version is pending
MYOPTIONS is an associative array you don't need to walk the whole looking for the looking for the right element.
Code:
get_myoptions_value ()
{ I=0
#SEARCH_OPTION=$(echo "$1" |tr -d "-")
SEARCH_OPTION=${1//-/}
while [ $I -lt ${#MYOPTIONS[*]} ]
do
#OPTION=$(echo "${MYOPTIONS[$I]}" |cut -d "," -f 1)
OPTION=${MYOPTIONS[$I]%%,*}" # the first comma-separated value
#VALUE=$(echo "${MYOPTIONS[$I]}" |cut -d "," -f 4)
VALUE=${MYOPTIONS[$I]##*,} # the last one (this might not be 4)
#[ "$OPTION" = "$SEARCH_OPTION" ] && (echo $VALUE ; break)
[ "$OPTION" = "$SEARCH_OPTION" ] && { echo $VALUE ; break ; }
#I=$(expr $I + 1)
(( I++ ))
done
}
That's not more efficient it's doing a ueless array walk and it's less readable, but yes instead of forking cut I could have removed the longest matching prefix ... that might go in the revised version.
eval $(echo dialog --title \"$TITLE\" --yesno \" ${STRING[*]}\" 0 0 ) && return 1 || return 0
# can be simplified by:
dialog --title "$TITLE" --yesno " ${STRING[*]}" 0 0
# you can put a return $? if you want at the end, but not required
in general you should eliminate eval, which will not only speed up the execution, but as you can see makes the code more readable (and also shorter)
eval $(echo dialog --title \"$TITLE\" --yesno \" ${STRING[*]}\" 0 0 ) && return 1 || return 0
# can be simplified by:
dialog --title "$TITLE" --yesno " ${STRING[*]}" 0 0
# you can put a return $? if you want at the end, but not required
in general you should eliminate eval, which will not only speed up the execution, but as you can see makes the code more readable (and also shorter)
We have already discussed that ... it will go in the revised version.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.