A bad thing about ALFS in c

Felipe Contreras al593181 at mail.mty.itesm.mx
Thu Nov 8 10:05:44 PST 2001

On Thu, Nov 08, 2001 at 05:23:57PM +0100, Neven Has wrote:
> Language independence of the backend. So that, for example, creating of
> directories can be done with mkdir(3) (through a shell), or fully implemented
> in the handler (some "stripped down" mkdir(3) using mkdir(2) if backend is
> in C) or, if backend is written in Perl his mkdir() etc.
> Well, at least that _was_ the idea. :)

Well, it is a good idea, but anyway it should be posible to write shell
commands, and that is hard to be independent of the shell.

> I know that reinventing mkdir(3) (nor using it _through_ C or some other
> language) doesn't make much sense. One of the advantages of rewriting it in C
> might be speed, but the difference (calling external command or not) would be
> really silly. The other advantage that comes to mind could be independence
> from the shell itself. But that's also pretty impossible since there are
> things like patch, configure etc. for which one would have to do exec(2)
> directly and again - act as a shell in a way. For example.

Sure, so it's hard to tell which commands should be declared on the
XML or inside <execute> tags.

> > So ALFS is in XML, but the XML data in which format will be? it needs to
> > have some kind of shell commands, doesn't it?
> Well, the original idea is no. Everything would be split into different
> elements (<mkdir>, <link>, <copy> etc.) and only some weird and
> not_worth_adding_a_new_element_because_of_it things would be in <execute>
> as shell commands. The way it is now, actually.
> But then we come to that really really weird stuff which isn't easy to execute
> through something like C (by calling a shell), for the reasons above, nor
> represented in XML.
> So now what? Should be dump the "backend language independence"?
> I could agree with that, but before (and if) we do it, we should really first
> create a nice protocol for frontend<->backend communication.
> That way, backend could be extremely simple bash script - it could just
> receive (already parsed by frontend) commands, execute them and report the
> exit status for each one. Something similar to your sourcer, but where
> xmlparse would actually be a daemon receiving the commands from the frontend
> (and not parsing XML profiles on its own).
> Well, just one of the solutions... :)

Sourcer uses xmlparser to parse commands from xml files, and xmlparser
doesn't do anything except extract commands and steps sourcer, since xml
files are too simple compared with the ALFS ones.

Well the idea of a backed bash script is good, but there are still
things missing. For example, how does the shell know if the input is a
series of lines, but all of them is a single command, like 'for x in *'
and so on. There is also the thing about dividing the commands into

I did something like that for sourcer and it worked well, but I'm
not sure if it's the best. The problem with it is that the backend again
doesn't report the status to the c program, so we need a pipe throught
them with an unused fd, and the bash backend should write to it.

Right now I think that's the best solution, but anyway I feel there
should be something better, I'm not sure, so I'll just keep thinking,
but what do you think?

Might be we should not stick with the idea that there should be one
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list