method scripts language choice
David Zeuthen
david at fubar.dk
Sat Feb 18 10:43:17 PST 2006
Hi,
Sorry for the delay,
On Tue, 2006-02-14 at 11:31 -0800, Artem Kachitchkine wrote:
> I get this schizophrenic vibe about these scripts: they are not pretty,
> certainly not trivial, so the only reasons I can think of for using
> shell are:
>
> 1. allow admins tweak them; or
> 2. it's an interim solution, will be rewritten in C.
>
> The former doesn't seem like a good administration interface - we want
> any customization to be done data-driven via gconf/whatever, not
> code-driven.
>
> Another concern is that these scripts are on the line of attack. As far
> as I can tell, securing shell code secure is harder than C code and a
> few security experts I mentioned "shell scripts run as root by a daemon"
> to invariably go "Ewww".
>
> What do you think, folks?
Good question, I'm certainly not super happy about using bash, but, eh,
I don't have any other ideas at the moment.
Pulling in perl or python seems to me like a non-starter, I certainly
don't want hal to require such huge packages partly because they just
wont fit on embedded systems e.g. Maemo or the $100 laptop. There is
also the concern there is a bug in the runtime; this rings true for
shell too. So not going to happen.
Writing things in C is... tedious.. I still remember the fstab-sync
program, so much code for doing so little... well.. at least we can and
should use glib and it will be less bad.
So I think initially writing things in shell and rewriting potentially
dangerous stuff in C once the interface has settled is the road ahead. I
note that this is the case for mount/unmount scripts... we could and
should write that in C now. Things like the power management scripts
should remain shell as they are trivial insofar that they don't accept a
lot of input.
How about that?
Cheers,
David
More information about the hal
mailing list