[ksh93-integration-discuss] Re: Planning the final ARC case forthe first ksh93-integration putback...

[Glenn Fowler]

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 --