[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: POSIXLY_CORRECT and install scripts

On Thu, Jan 02, 2003 at 10:01:04PM -0500, Greg Stark wrote:
> Joe Drew <hoserhead@woot.net> writes:
> > On Thu, 2003-01-02 at 19:59, Greg Stark wrote:
> > > It would be a good idea to have developers set POSIXLY_CORRECT at least once
> > > during testing their packages to ensure they aren't depending on some
> > > non-posix GNU behaviour in their packages. Ideally at least some developers
> > > should use it all the time to avoid such bugs at run-time.
> > 
> > What's the problem with depending on GNU behaviour? IIRC even the
> > Debian-BSD folk are going to be using the GNU runtime.
> Well mostly because users might have POSIXLY_CORRECT set and it would suck for
> programs to just randomly fail to install or misbehave in that case. 
> But even internally it's not really a good decision to depend on non-standard
> mostly undocumented behaviour. It makes it harder to interoperate with other
> systems if someone does want to use our packages on a non-debian system, it
> makes it harder to adopt new versions of programs if decide we like another
> implementation of something instead of the current one, and for that matter
> there's no guarantee the GNU programs won't change behaviour at some point in
> the future. Whereas we can be pretty sure POSIX mandated behaviour won't
> change, at least without notice.
> If a maintainer really needed a non-posix compliant feature and did
> "POSIXLY_CORRECT= foo" in the script I guess there wouldn't be a serious
> problem for Debian. But It seems like it would still be a bad idea. In any
> case there would be virtually no reason to ever feel the need to do that.
> Nearly all the changes POSIXLY_CORRECT makes are things like not permuting
> command-line arguments, using 512b blocks in df(1) (making df -k the norm),
> etc.

For the pedanticists on the list, I think you actually mean "making df
-B 512 the norm"; df -k is what we normally get.  The df documentation
does not mention its sensitivity to POSIXLY_CORRECT; df has a -P (for
POSIX) option that does something entirely different; and -B 512 is
about as obsolete a behavior as I could ever want as an example why
following POSIX is not always bright.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Reply to: