cvs commit: ALFS syntax.txt

Neven Has haski at sezampro.yu
Thu Mar 28 03:09:21 PST 2002

On Wed, Mar 27, 2002 at 09:55:35PM +0000, Mark Ellis wrote:
> > <remove />
> > 
> > No subtags or elements are needed.  I think we can all agree on this
> > ;)
> Oh i dont know, looks like a good place for a <base> :) Actually now i 
> think about it it does ! How about :-
> <remove>
>    <base />
>    <cant think of a name for this bit />
> </remove>

I don't remember anyone ever explaining why this is the only element
without <base> or any other sub-element. I don't know if this is the
exact reason (if any existed at all), but I think it would be better to 
stay with the way it is now because it's much less error prone. It's
harder to make mistakes (and wipe your disk clean) when you have to type
the full path of the file you want to delete.

Also, I would like very much that we add <option>recursive</option> here
and set default to just a simple rm(1)-like operation.

That would make screwing things up even harder.

> > Similar to unpack.  However if we use <option /> with configure and
> > make
> > (and other tags), the usage of <options /> may seem confusing.  It may
> > perhaps make more sense to just use <option /> also, while allowing
> > multiple tags. (so if you need say resursive and resursive, you have
> > two options, one for each)
> > 
> Stick with param for the others, see above. Multiple tags for multiple 
> options, sounds reasonable.

Yeah, I like very much multiple <option>s here.

> > <mkdir />
> > 
> > <mkdir>
> >     <base />
> >     <dir />
> > </mkdir>
> > 
> > Will talk more about this when i get around to the base/dir issue.
> Got an <options> in there too, to create parent dirs if necessary.

<option> ! ;)

I can't think of the reason we used <options>foo bar</options> in
a first place. :)

> > <setenv>
> >     <variable />
> >     <value />
> > </setenv>
> > 
> > I'm presently using this too, which was taken from nALFS.
> Dunno exactly what Neven is doing with this, but i treat an empty 
> <value> as setting the var to a null, and no <value> element as 
> unsetting the var.

Could someone clue me by explaining me the difference?
I'm unsetting the variable (unsetenv(2)) in both cases.

> Assuming <base> refers to the directory from which all ops are 'based', 
> the only common usage of <dir> i'm familiar with is in <mkdir> yes ? In 
> which case, rename that <dir> as <name>, or even <target>, though i'd 
> prefer <name>, you're making a dir so <name> shouldn't be ambiguous.

<name> is nice.

> Stuff i've got that you havent, for whatever reason.
> <chroot dir="...">
> </chroot>
> This one also came into the generic container thread.
> <patch>
>    <base />
>    <param />
> </patch>
> Always considered patch a bit odd, 'cos without an "optional" param its 
> useless. Maybe needs a rethink.

Hm, the same argument as for <configure>, someone brought up. I can't make
up my mind whether to just use <execute>, with <command> being the thing
that distinguish them, or not.

I believe we could think about what elements can be implemented without
calling the external program. All those that can not, could be just

There is something to be said about having distinguishable elements for
different actions, but in the end, it's still system command needed to be

But on the other hand this might be a bit extreme, since <make> also
belongs in this category. And we all kinda grow to it. :)

> <search_replace>
>    <base />
>    <file />
>    <find />
>    <replace />
> </search_replace>
> Invaluable to all but the previously mentioned sed gurus :)
> <textdump mode="append | overwrite">
>    <base />
>    <file />
>    <content />
> </textdump>
> Default is overwrite.
> Those last two in particular will probably start the <execute> vs 
> specific elements thing again :) Depends what you're trying to achieve, 
> either encapsulating shell commands in an automated build system or 
> creating a build system with its own syntax. Both equally valid goals, 
> personally i like specific elements.

Why these last two? I think they clearly belong in "having a separate
element" category. We don't need to use a system command to implement


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