On Thu, 16 Nov 2006 11:10:00 -0500 James Carlson wrote:
> Glenn Fowler writes:
> > it is getting a bit clearer:
> > a user application with PATH=$(getconf PATH) can use getconf to
> > check the parameters for any other utility/application on $PATH
> > but once PATH is modified, some utilities/applications may not
> > correspond to getconf
> I'm not quite sure I follow. If an application uses PATH=$(getconf
> PATH), then it has entered the POSIX.2 environment. If it was
> previously in XPG6, it stays there (as that's a superset), but if it
> was in any "lower" environment, it goes to POSIX.2.
I was thinking "user shell script application" and should have typed it
once a script strays from PATH=$(getconf PATH) it may come across utilities
on PATH that have parameters different from what getconf tells the script
> > for xpg in 000 300 400 402 500 600
> > do
> > case $xpg in
> > 600) cc=c99 ;;
> > *) cc=cc ;;
> "cc" doesn't give you a standards-compliant XPG4 environment, per the
> standards(5) man page. It's used for SVID3 and CAE XPG3.
I found that out for c99 when cc refused to compile xpg 600
cc did not complain for xpg 400 402 500 (and no hint to use c89)
giving me a false sense of success
[45]*) cc=c89 ;;
and that clears it up for me
from a portability+extensions standpoint I almost never stray from plain [g]cc
this has been a good exercise
it also shows that its not worth losing your sanity programming to standard
limits
code for no limits when possible and be blissfully clueless of standard
conundrums
thanks
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
