Example, thoughs?

Jesse Tie-Ten-Quee highos at linuxfromscratch.org
Mon Mar 4 02:01:50 PST 2002


On Wed, Feb 27, 2002 at 11:36:57AM +0100, Neven Has wrote:
> Actually, only <options> are used for elements like <copy>, <link>,
> <move> etc. for things like "force", "archive" etc. <param> is still
> used for <configure> and <make>.

I know.  I was trying to see if i could replace param with option ;)

> But we could perhaps use a single element (<option(s)>) for both cases?
> Although they are not really the same thing - with the <configure> and
> <make>, they are just appended to the executable and executed as a system
> command, while with <copy> and friends they are recognized, after which
> the parser acts accordingly (depending on the implementation).

Maybe.  This is where nitpicking can get annoying, so many small details
need to be worked out ;)  What if we used empty tags like <archive />,
<force /> and so forth?

> I guess you are using a symbolic linking as a default here? I'll have to
> change that in nALFS too, which now requires that the type is specified
> (not sure why I did that).

Uh, yes.  It's default and i presently have no support for hardlinks *g*

I guess, if you follow what i was mentioning above we could go with
<soft /> and <hard />.

> This is becoming confusing. :) <base> or <dir>? If we start using <dir>
> again, what shell we do with <mkdir>?

Well, i'm still confused about what everyone suggesting the best method
would be.  So i've continued to use what i've always used.


Is an example of my idea of just letting mkdir have no arguments.  Dunno
still.  I've been thinking about your and Mark conserts about having
additional options for such things as copy, link, move, etc.. so mkdir
problably falls under that category also.

However, i still think mixing base and dir together is not a good idea.

> These are also different. Personally I prefer <target> and <name> - I think
> they are clearer (name of the link and target to which it points to) and
> they are also used by ln(1) which is what people are already used to?

Perhaps.  That is where ALFS is going unless someone comes up with a
better suggestions.

Jesse Tie-Ten-Quee  ( highos at linuxfromscratch dot org )
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