Hi Laszlo !
>Let us see if we can more productive then!
Sorry, I haven't been able to pick up this earlier, due to lack of
time here.
Your approach is to unify things in different projects. Right?
I completely agree, it is a good approach to have common
solutions, to be used in different kinds of systems, if those
solutions fit there needs.
The only disagreement is the way you like to force a special
solution (which can be solved in different ways) going into the
main Busybox binary. All your request can be done using some
scripting, when thinking carefully.
Busybox ntpd allows all systems to provide all required
information during start of the daemon. There is no need to add
any extra code to the binary. To unify things just define in
which file and how information is placed there ... and request
(ask) all projects to accept and use this definition. That is the
main part.
>From there it is the system/distro maintainers job to provide
scripts to pick the information and call BB ntpd with the right
arguments. Even if the scripts between systems differ, you are
fine, when all those projects agree and use the information from
the file you defined. It is up to the system maintainers if they
use a common template and throw in there own stuff, or decide to
write there own scripts.
As you have seen, there are different approaches to store the
information, so I try to give you some background on how
things are handled in the good old Unix way.
In principle there a two different kinds of solutions to store
and retrieve config information in the controlling scripts.
Either you write your config in the shell style and source the
config file, or you put this in your own format and use any kind
of filter to pick the required information. Both approaches have
there pros and cons.
The simple way is to use shell style in config files, that is
basically the VARNAME="value" style, but using some clever
function definitions you may create your own syntax.
file /etc/timeserver:
timeserver my.local.server
timeserver ntp1.ptb.de atom.uhr.de
the controlling script:
TIME_SERVER=""
timeserver() {
local arg
for arg
do if valid_addr "$arg"
then TIME_SERVER="$TIME_SERVER -p '$arg'"
fi
done
}
source /etc/timeserver
eval ntpd $TIME_SERVER
Beside this you may have any number of comments in your config
file and you may use shell style substitutions to build some
variable content from values of other configured values. On the
other hand the big problem is, the config files are sourced, that
is a shell executes every command in those files, even if one
enters a line with "rm -rf /" it is executed as is, so you need to
carefully watch, whom you give write access to such kinds of
config files.
To avoid this you can use any kind of filter to pick the
information from the file you like. I gave you the very simple
`cat FILENAME` example, someone else provided an sed filter to
pick the server name from a default ntpd.conf file. It just
depends on complexity of your filter on how you can define and
pick the information from your file(s). For simple solutions you
do not need to use other filters except some shell scripting:
while read line
do case "$line" in
'' | \#* )
;;
timeserv\ * | timeserver\ * | server\ * )
set -- $line
shift 1
for arg
do if valid_address "$arg"
then TIME_SERVER="$TIME_SERVER -p '$arg'"
fi
done
;;
esac
done </etc/ntpd.conf
>How about the following two files:
Details have already been discussed. The files may or may not fit
project needs, we can't tell you. Only the system maintainers
can decide if such scripts fits there system policy.
--
Harald
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
