On Fri, Jan 13, 2006 at 07:47:48AM -0700, Eric Blake wrote: >>P.S. I know that Cygwin isn't fully compliant with POSIX >>specifications. > >One other thing to be aware of. If cygwin does define _POSIX2_VERSION >in its headers, programs will assume that all features specified by >POSIX are available. Coreutils, in particular, makes a compile-time >decision about the default behavior of some of its apps, based on the >value of _POSIX2_VERSION (of course, this decision is overridable at >runtime by redefining _POSIX2_VERSION in the environment). An example >of this would be that right now on cygwin, with coreutils 5.93, "tail >+4" defaults to the 1992 POSIX semantics of "tail -n +4", because >_POSIX2_VERSION was not detected at configure time. But if you start >adding _POSIX* macros to features.h, to be more like Linux, and choose >to move to the 2001 version of POSIX, then a recompilation of "tail +4" >would default to the semantics of "tail ./+4".
I was just reviewing this thread to begin thinking about preparing a plan of attack for this problem and I see that I forgot to thank you for this insight. This is exactly the kind of feedback I was hoping for. While I suspect that turning on _POSIX_SOURCE in cygwin's feature.h and cleaning up the fallout from that action in the header files may make some programs easier to port, I was wondering what the other side-effects would be. So, it sounds like the effect would be to make some applications behave more like linux, which is theoretically a good thing. But, since it will be a change in visible behavior, we may see some complaints. Actually, strike the "may" and substitute "will". cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
