robert at linuxfromscratch.org
Sun May 6 16:30:13 PDT 2007
Hello. Is it worthwhile to add a "posix syntax", or "posix compliance",
role/feature? There are only a few things I am aware of at the moment:
'head -1' should be 'head -n 1' (or --lines=1)
'tail -1' ... 'tail -n 1' (or --lines=1)
'tail +16c' should be 'tail -c +16' (or --bytes=16)
'if [ something != something_else -a -r $foo ]' should be
'if [ something != something_else] && [-r $foo ]'
Almost all packages expect head(1), tail(1), and test(1), to be GNU or support
With a bit of searching I could probably find the Posix and ISO standards for
the 'standard' options and behavior of these applications, so the
justification for posix-patches can be documented in the book. In general I
have found package maintainers are happy to add compliance fixes, as long as
they're portable... 'head -n 1', while it may be defined as standard, is not
portable in-real-life because not all head(1) programs support the '-n'
These issues affect almost every package, although they're largely fixed in
packages which use new versions of Autotools, and packages used by many
operating systems (like GCC). This affects 24 files, involving approximately
22 Sed commands, just with GCC-4.1.2 (including java, etc) and Binutils-2.17.
There are certainly more examples, and some may dip into C code and
application features. There is a quick fix for 'head -1', by using ' | sed
This is mainly an issue when using non-GNU applications, like Busybox, which
may not support non-standard options or extentions.
I see a few options of dealing with this:
Fix everything, including Makefile.am's and configure.ac's, with patches or
elegant Sed commands, whichever is more practical. Running autoreconf with
posix-syntax compliant autotools macros will often not be enough to fix all
the scripts in the package. I like this option best because it is the most
correct option, but it is also the most work with the least gain.
Only fix scripts which are actually installed, such as '/usr/bin/gccbug'. This
is perhaps the most practical option.
Do as little as possible, and only offer patches when a problem is found, like
if Busybox can't use '/usr/bin/gccbug'. This is the most bug-prone option,
and the least amount of work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev