cvs commit: ALFS syntax.txt

Mark Ellis mark.uzumati at
Thu Mar 28 02:25:14 PST 2002

On 2002.03.27 23:09 Lee Saferite wrote:
> On Wed, 27 Mar 2002 22:42:29 +0000
> Mark Ellis <mark.uzumati at> wrote:
> > On 2002.03.27 20:52 Lee Saferite wrote:
> > > Here is an ALFS-DTD I was working on, any comments?  (yes, I just
> > > modified the ALFS-DTD-2.0.2 fiel)
> >
> > I wouldn't bother with a <touch> element. If you want to create an
> > empty file do a <textdump> with empty <content>. I would imagine the
> > occasions this will not do are so rare you might as well just
> <execute>
> > touch.
> The thing is, getting away from using <execute> is, IMHO, a good Idea.
>  And while I realize, now, that textdump could create an empty file
> for you, what about using <touch> for it's real purpose? Changinf file
> timestamps?  Is this something you think you would never need?  I
> don't know, I just added is because I thought It would be useful. =)

Always gonna be a toughy, the whole balance between minimalist and 
catering for everything, and i seem to switch sides periodically. This 
seemed useful, just a bit over the top. Maybe we need a core syntax and 
a set of standard extensions ?

> >
> > I've made by preferences on the <option> vs <param> debate plain on
> too
> > many occasins to repeat them again :)
> >
> Disclaimer:  I haven't read all of your arguments, or even most of
> them.
> I would think that a common <option> or <param> argument would be a
> good thing.  You choose one or the other and use it for ALL the
> elements.  I mean, look at all the man pages.  They all say [options],
> even the help for configure says [options], why should we have a
> <param> element when the most common term is 'options' (hence the
> <option> element)?

Ok, i'll go again. The naming is perhaps slightly misleading but the 
<param> and <options> are very different things. <param> is a direct 
interface to the usage of the underlying command, whereas <options> 
provides an ALFS specific interface to certain functionality. The 
problem with using the same tag for both is that it suggests you can 
use cp(1), mkdir(1) etc options to the corresponding handlers when in 
fact this is not the case. So they do a similar job, ie. altering 
command functionality, but at a different 'level', is the best way i 
can express it. If an ALFS implementation used shell commands then yes 
you could add <param> too and pass its contents to the command, but 
that then ties the syntax to a specific platform. Yes <make> and 
friends ties us down, but we have little choice there, unless someone 
wants to rewrite make in ALFS :)

> > I notice you left <command> out of <make> and <configure>. I agree
> that
> > adding a different command to these turns them into <execute> in
> > disguise, it might just be more self documenting to have this
> > capability in the profile.
> >
> I figure, if you need to do a <command>, then you should use the
> <execute> or find another way to do it.  if you have a strong enough
> set of core elements, you don't need that kind of fluff.  Sorry if I
> make anyone angry.  ;)

Swings and roundabouts thing isn't it, i like it from a documentation 
point of view, easier to find a make step if its called make, even if 
it uses myownbuildscript.exe.

Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list