>Date: Thu, 09 Nov 2006 13:21:41 +0000 >From: Darren J Moffat <Darren.Moffat at sun.com> > >Casper.Dik at Sun.COM wrote: >>> Don Cragun wrote: >>>> We also propose to replace the file /usr/xpg6/bin/xargs with a link to >>>> /usr/bin/xargs, so that old programs that may have hardcoded the path >>>> to the XPG6 version of xargs can continue to operate properly. >>> Is this intended to be the architecture of reference for when we fully >>> unify an xpg?/bin variant with its bin variant ? That is symlinks must >>> be provided ? >>> >>> I'm okay if that is the case, I just want to know of this case is >>> setting new case law. >> >> >> I thought we never used the full pathnames and that setting $PATH was >> the only supported way? > >That is what I believe POSIX requires because the pathnames are vendor >specific. > >However we know that people do stuff like /usr/xpg4/bin/id in script and >my understanding was that the project team believed that those scripts >shouldn't break (in this case it is xargs). I was asking if this is the >stance we want to take or do we want to take the strict POSIX stance. > >In some ways I believe we already have case law to cover this in the >case that moved /usr/proc/bin/* to /usr/bin.
Casper & Darren, The only way for a POSIX.1-2001 conforming application to find a standard utility is to set PATH to the implementation specific value that specifies where the standard utilities are located. But, having done that, an application can search that path for the location of any given standard utility as part of an initialization process and then use an absolute path to execute it. Since this search could be run at application installation time, I think it is necessary to install the symlink for this case. The project team is not trying to set precedent by doing this, but I would expect it to be used frequently in similar cases to avoid backwards compatibility problems. - Don > >-- >Darren J Moffat
