question to postfix instructions (long)

Larry Lawrence larry at
Wed Mar 24 12:31:33 PST 2004

"Reinhard" <bookreader at> wrote in message
news:200403241829.00445.bookreader at
> Thank you, Larry, for your attention.
> On Wednesday 24 March 2004 15:42, Larry wrote:
> > > I found a little conflict in the sed-command, cause the '/' in
> > > </replaceable> matches sed's s/// delimiter.
> > > Is it possible, to use another delimiter for the sed's 's'-command?
> >
> > Have you experimented with xslt to clean up the source files prior to
> > converting them to instructions.
> No, I don't use xslt. I use perl with a self-written xml-engine, so all
> conversion is done by myself.
> I supposed that the  <replaceable> ... </replaceable> is used to trigger
> editor from nALFS, so I wanted to keep that untouched for the
> profile-migration.

As far as I know <replaceable></replaceable> shouldn't be used by alfs in
any shape or form.  It is used by an editor (person writing) to identify
strings that must be changed prior to executing the command.  In most
renderings, the string is in italic to get it noticed.  It works nicely
because users that cut-n-paste from rendered copies never pick up the
<replaceable></replaceable> because it was stripped during rendering (in
this case xml source -> DSSSL stylesheets -> html).
> I think, the sed-command could be written i.e. as
> sed s%...<replaceable>...</replaceable>% ... %
> and there would be no harm to nobody.
> This variants are used all over blfs - so I pluck up courage to ask for a
> change.

Yes, it could.

> Same problem I found in configuration-section of mplayer.
> There's a link command with ...<replaceable>[font size]</replaceable>...
> AFAIK unquoted filenames in X-World may not contain spaces.
> So how about to change [font size] to [font-size].
> With that little change, the rules for filename are met and the
> <replaceable>...</replaceable> could be transferred to nALFS-profiles.

Again, my primary concern is to the reader, so my preference is how it is,
but the change your proposing is not one that I would contest.  I am having
trouble following the 'filename' examples here.  In this case,
'<replaceable>[font size]</replaceable>'  needs to be converted to '18', for
example.  This is user chosen within valid parameters, so at some point this
has to be defined by the user during the automation process and then
substituted into the instructions by alfs for execution.  There are several
ways to do this and I can't standardize the source for all of them.  As the
"proof of concepts" unfold, I should be able to determine the 'most likely'
winner and then I can verify that the source is compatible.

> > The transformation process is progressing.  The newxml for LFS is the
> > stage of the utopia world where all LFS projects use the same source.
> I appreciate that idea! No more wasting time by editing the same in
> locations - great!
> > Currently, it is critical that the source works for it's primary
> > then namespace extensions will be added to ease the transformation
> > to alfs profiles.
> The namespaces and xpointer work great! - Lot of hardcoding could be
> with the new format.
> One question about dependencies.
> I have the glimpse, the (some) editors don't like to have the dependencies
> meet the installation instructions.
> How about to add the (unwanted) dependencies in an entity-section, so the
> information is there (in the book), but does not get rendered to the
> HTML-variant.
> Could that be a compromise?

Are we talking about dependencies outside the BLFS universe?  An example I
ran across today relates to OpenSSL which will utilize 'Kerberos', it is not
listed in the book yet, and based on what I have gathered from Google and
personal experience, it won't be.  Main reason, it will not compile.  If I
put a dependency in the book, I have to believe it is usable by my 'average
user', so testing is an issue here.  Make some suggestions, I feel like I
can justify all the dependencies in the book as they are based on feedback
and usage, but I have no problem walking through them here for review.

> > As much as we would like for this to be done already, it is making a lot
> > progress.
> Let me know, If I could help.

> Cheers Reinhard


More information about the blfs-dev mailing list