[blfs-dev] bash script

Ken Moffat zarniwhoop at ntlworld.com
Mon Jun 2 07:23:46 PDT 2014


On Mon, Jun 02, 2014 at 11:57:40PM +1200, Christopher Gregory wrote:
> Hello,
> 
> Well I have spent hours looking through the man pages on time(2), bash,
> and trying to modify the SBU calculation script that jhalf uses to work as
> a standalone to no avail.
> 
> The script at:
> 
> http://lists.linuxfromscratch.org/pipermail/alfs-discuss/2005-December/007441.html
> 
> which has a few more features than the one on Bruce's SBU page:
> 
> http://www.linuxfromscratch.org/~bdubbs/about.html
> 
> is what I am using, with the program name modified accordingly.
> 
> what I need is the value of Elapsed Time set to a variable so that I can
> divide it by the base_sbu value of bin-utils.
> 
> I know that I can manually do this, but I really do need it to work in a
> script.
> 
> The examples I have found on google are no help to me.
> 
> There has to be a way to just pass the integer value of Elapsed Time to a
> variable without getting the frigging error that it is not an integer
> value.
> 
> I know from the research that time outputs to stderr.
> 
> I am NOT a scripter nor a very good programmer as I normally hate going
> around in endless circles going no where.
> 
> Regards,
> 
> Christopher.
> 

 My current scripts are a bit more involved than that.  I still
calculate an SBU value, but only because I used to.  In the
beginning, I stored $SECONDS.

 Now, I use the following (actually, I have a lot of debug code as
well, and I've reformatted this slightly) -

km_start_SBU () {
        # start the package's SBU timing from here, after it has
        # been untarred
        KM_DOING=$(date +%s.%N | awk '{ printf "%8.3f", $1 }')
}

km_end_SBU () {
        # stop the timing : called from km_finish()
        KM_DONE=$(date +%s.%N | awk '{ printf "%8.3f", $1 }')
}

km_calcSBU()
{
        # calculate its SBU
        # first calculate the elapsed time
        KM_MYTIME=$(echo $KM_DOING $KM_DONE | awk '{ printf "%8.3f", $2-$1 }')

        # if the SBU stamp exists, read it
        if [ -f $KM_SBU ]; then
                KM_SBUTIME=`tail -n 1 $KM_SBU | awk '{ print $NF}'`
                # now set the sbu without a newline
                KM_MYSBU=`echo $KM_MYTIME $KM_SBUTIME | \
		 awk '{ sbu = $1 / $2 ; printf("%3.1f",sbu) }'`
                # minimum value is less than 0.1, not 0.0
                if [ $KM_MYSBU = "0.0" ]; then
                        KM_MYSBU="less than 0.1"
                fi
        else
                # set the SBU from first package (assumes a straight
                # LFS build)
                # and therefore own time is 1.0 SBU
                echo $KM_MYTIME >$KM_SBU
                KM_MYSBU="1.0"
        fi
}

 The key thing, as with any script, is to use the tools which are
available.  In my case, I use awk for doing the maths.

 I suggest that whole seconds are probably perfectly fine for most
usage of SBUs, there is always some variation between different runs
(and nowadays the variation has increased if I use the ondemand cpu
governor, so I've now stopped using that for measured builds).

 A couple of other notes:

KM_MYSBU points to a file which holds the elapsed time in seconds
and decimals for 1.0 SBU, and the last line is what I use - after
the system is completed, I recalculate the SBU to see how it
compares to the SBU from the host system, so that recalculation uses
its own code to append a new line.  That value is what I actually
use as the divisor when measuring packages for the book(s), but for
the measurements themselves I normally do a DESTDIR build and time
each step individually, then use a calculator.

All the KM_ and km_ prefixes are because _something_ broke when
bison got upgraded a year or so ago (i.e. bison would either not
compile, or its testsuite broke, I forget which).  One of my
variables or functions had a name which the bison devs had decided
to use.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.


More information about the blfs-dev mailing list