Make bootscripts more POSIX compliant

Matthew Burgess matthew at linuxfromscratch.org
Thu Feb 22 11:35:17 PST 2007


On Thursday 22 February 2007 19:05, Dan Nicholson wrote:
> On 2/22/07, Matthew Burgess <matthew at linuxfromscratch.org> wrote:
> > Thanks Dan.  The patches look fine to me.  Just one question though.  In
> > patch 1, would it not be cleaner to simply use `printf' rather than try
> > to find a non-broken `echo'?
>
> That was the discussion with Bruce here:
>
> http://linuxfromscratch.org/pipermail/lfs-dev/2007-February/058937.html

Uggh, I did read the whole thread before replying, honest!  Obviously not 
close enough though, sorry!

> The problem with using printf is that POSIX doesn't say that it needs
> to be a builtin (although it is in dash) and the coreutils executable
> is in /usr/bin.

Well, I think that POSIX does state that printf should be a builtin.  There 
are codes that appear in a utility's Synopsis section, which determine 
whether it is optional or mandatory.  Compare, for example, the 
specifications of 'admin' and 'alias' to those of 'echo' and 'printf'. (I 
don't want to paste links as free registration is preferred by The Open 
Group).

> The other reason is that most of the LFSers seem to be 
> more familiar with echo and not as familiar with the printf syntax.

I'll agree with that, though the syntax of printf is easy enough to 
intuitively understand for our use-cases.  As we'll only be outputting 
strings, the format specifier isn't required.  We just need to add a '\n' to 
each of our strings to force a newline.

> The first patches I attached at the beginning of this thread used
> printf. I don't feel that strongly either way, so it can certainly be
> discussed further. In either case, it requires the script to use a
> different syntax ($ECHO or printf) if they need the escape sequences.

I don't feel strongly either way either.  I just think that printf's syntax is 
easier to figure out straight way than working out why we need to use ${ECHO} 
and how/why we set that variable up.

Feel free to commit whatever you're more comfortable with, Dan.

Matt.



More information about the lfs-dev mailing list