posix syntax

Robert Connolly 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 
GNU options.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070506/63545544/attachment.sig>

More information about the hlfs-dev mailing list