Mail Archives: cygwin/2006/01/16/15:05:16
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/
- Raw text -