Mailinglist Archive: opensuse-factory (487 mails)

< Previous Next >
Shell script optimization was: Re: [opensuse-factory] RFC: to upstart or not
  • From: Guido Berhoerster <guido+opensuse.org@xxxxxxxxxxxxxxxx>
  • Date: Sat, 15 May 2010 12:47:23 +0200
  • Message-id: <20100515104723.GB7189@xxxxxxxxxxxxxxxxxx>
* Lars Vogdt <lrupp@xxxxxxxxxx> [2010-05-14 20:42]:
What about having a look at (and maybe optimizing) our current init
scripts instead?

I'm currently searching for a good page about "optimizing bash/init
scripts" - is there something better like
http://elinux.org/Optimize_RC_Scripts ?

That one looks reasonable for a start, it also recommends writing
portable rather than bash-specific scripts ;)

=> Is there someone who has good examples and can write something
into our wiki or here on the mailinglist?
(Something like "use 'case' instead of 'if' in the following cases...)

The most important thing is to keep in mind that each use of an
external command implies a fork()+exec(). Hence, using
functionality of the shell and builtins is usually preferrable in
terms of performance but there are exceptions e.g. when
processing a lot of data the speed gains of an external command
may exceed the performance penalty of the fork and exec (more
concrete example below). Often excessively long pipes mixing
cut, grep, sed, and awk can be consolidated in a single sed/awk
command. Another thing is to avoid subshells when possible,
however this is more complicated as its use is sometimes
implementation-dependent (e.g. in the handling of pipes) and
requires an understanding on how your shell works internally.
IMHO it is more important to understand the underlying concepts
of the shell, to use good judgement based thereon and to do some
actual testing rather than applying off-the-shelf recipes.
Having made my point, I'll make a start with some "recipes"
(all only relying on SUSv3 features):

# grep can be avoided where shell globbing is enough (at least
# when processing not too much data, particularly bash's globbing
# seems to be slow)
grep xxx foo.txt

while read -r line; do
case "${line}" in
*xxx*) printf "%s\n" "${line}" ;;
*) ;;
esac
done < foo.txt


# the shell itself can be used to split strings rather than cut
# or awk

input="johnd:x:1000:1000:John Doe:/export/home/johnd:/usr/bin/ksh93"

printf "%s\n" "${input}" | awk -F: '{ print $5 }'

ofs="${IFS}"; IFS=":"
set -- $input
printf "%s\n" "$5"
IFS="${ofs}"


# the shell's parameter expansion can sometimes replace command
# substitution using sed or some specific commands

filename="/foo/bar/baz.xxx"

printf "%s\n" "$(basename "${filename}" .xxx)"
basename="${filename##*/}"; basename="${basename%.*}"
printf "%s\n" "${basename}"

printf "%s\n" "$(dirname "${filename}")"
printf "%s\n" "${filename%/*}"

=> Is there someone who like to help reviewing the current init
scripts of our distribution?

Yes, I've got a rpmlint check for checking /bin/sh-Scripts for
bashisms ready but it hasn't been itegrated yet. When it is in
place I'd like to review (init) scripts anyway in order to
fix any bashisms, if optimizations of the init scripts are
welcome that could be done along the way.
Having fixed /bin/sh scripts would then open some further
possibilities, like easy switching between at least bash, dash,
and ksh93 as /bin/sh as it is e.g. possible in Debian. Based on
preliminary testing dash as /bin/sh seems to have a rather little
performance impact on the boot process by itself.
It would however be interesting to experiment with ksh93 as
/bin/sh since it provides a fair number of builtins (which can be
easily extended) as well as shcomp which allows to compile shell
scripts.
Unfortunately not many people seem intersted in this area,
openSUSE lacks a Shell/Tools-Team.

--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >