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