This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Output of "uname -s" and "uname -o"


On Tue, 10 Jun 2008, Christopher Faylor wrote:

> On Tue, Jun 10, 2008 at 10:56:14AM -0400, Igor Peshansky wrote:
> >On Tue, 10 Jun 2008, Christopher Faylor wrote:
> >> Maybe it isn't clear.  This may be new territory to you but we have
> >> already done things like changing the size of a structure by using
> >> #define (and other) trickery in Cygwin even before transitioning from
> >> stat64 to stat.  You also need a new function, of course.
> >
> >Right.  It's not new territory at all -- I know it's been done in Cygwin
> >before, so I don't quite understand why the issue of changing the size of
> >the struct keeps coming up.
>
> Once again: 1) Neither Corinna or I think this is a big problem and 2)
> It changes externally visible behavior which people rely on.
>
> You are characterizing this as an issue which flares up and dies down
> without resolution.  That is not the case.

Understood (though this has nothing to do with the mechanics of actually
implementing such a change, should Cygwin choose to do it).  It's the
mechanics issue being brought up that confused me a bit.

> >>I haven't seen any good explanation of how you'd deal with any
> >>application which is relying on the current behavior since you'd be
> >>breaking externally visible backwards compatibility.  That's the
> >>difference between changing the structure size for uname versus
> >>changing the structure size for stat or terminfo.
> >
> >By the current behavior you mean the fact that the underlying Windows
> >information is appended to the sysname field?  In one of my previous
> >messages I suggested adding a CYGWIN-env flag to force the old
> >behavior:
>
> We add settings to the CYGWIN variable only very grudgingly and I can't
> see how this would be a good idea in this case.  If you released a
> program or script which relied on this behavior you'd have to tell every
> user to set the environment variable or (ick) set the environment
> variable in the program itself.
>
> The mailing list would be filled with
>
>   >I try build blorp and it say unable to guess system type.  I reinstall
>   >five times but still doesn't work.  blorp not build cygwin?
>
>   Read the FAQ!  This was mentioned an hour ago in this mailing list.

Not necessarily.  Scripts that simply want to check for Cygwin will need
to recognize both "CYGWIN_*-*" and "Cygwin" (a simple change that is
forward-compatible).  Scripts that actually care to distinguish between NT
and 95 and XP (few and far between) will need to change their tests, but
again, not a big deal.  Scripts and programs that have not yet been
updated will run as before with an environment variable set -- this is
similar to the "no CRLF in scripts" bash change or the "no-extension files
take precedence over .exe files" change in Cygwin, and probably just as
disruptive; yet people live with both.  Yes, I had to change my scripts
for the two changes I described.  Yes, I will have to change my scripts
again for the uname change.  I don't see it as a big disruption, overall.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]