This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
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