On 4/22/06, Dieter Baron <dillo@danbala.tuwien.ac.at> wrote:
> In article <20060422193522.GA15336@britannica.bec.de> joerg@britannica.be=
c.de wrote:
>
> : Exactly. But calling an external program is good and necessary since it
> : is a prequirement for proper priviledge separation. E.g. if we have a
> : tool like dselect or aptitude or whatever, I definitely want to run it
> : as non-root, but the actual installation has to be done as root of
> : course.
>
>   I see.  I never considered being able to run the GUI as non-root
> when installing/deleting packages, but I see why one would want to.
>
> : Don't get me wrong, a wrapper library to ease the use is perfectly fine
> : and valid, but as primary interface, the command line is better IMO.
>
>   You mean a library function interface that does the program
> invocation, possibly with just-in-time-su?  Sounds reasonable.

There seem to be quite a bunch of programs that go this route.  One
example that comes to my mind is Monotone, which refused to create a
shared library and instead made a command line interface that is easy
to automate.

One advantage of this approach is that, with a correct and consistent
CLI, one can develop a nice automated testing suite that tests both
program internals and the external interface.  (And it also allows for
the privilege separation Joerg mentioned, something that I did not
consider.)

Cheers,

--
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/