The uname response

[Gordon Watts (Brown University)]

Hi,
  I'm starting to look at b20.1. We have a fairly large install and we have
a number of utilities that allow us to do package distribution from a single
database to many platforms (including things like install scripts, etc.
etc.). Nice utility. Unfortunately, it determines the flavor of the OS by
looking at uname.
  B20.1 has really changed uname a lot. :-)
  In B19, `uname` returned "CYGWIN32_NT". It now returns "CYGWIN_NT+4". And
uname -r returned "4.0" in B19 and now returns a horrendus string with lots
of spaces in it and other nasty things like that. Needless to say, this
breaks everything. :-)
  First of all, uname shouldn't return a "+4", should it? That "+4" is a
version number and not a machine name. I understand why you are doing
that -- we have both NT versions and cygwin versions. I can get around that.
But the dropping of the 32. Is the core bit of that string, CYGWIN_NT, going
to stick with us? There are already lots of packages that use the
CYGWIN32_NT string to label the software, so changing to CYGWIN_NT is going
to be a fair amount of work and frustration for people. I don't want to push
people unless I have to unless this is the last time.
  Also, the "+4" causes me problems because the software is structured with
the idea that the response to "uname" is constant, and the response to
"uname -r" changes with time as the OS gets better and better. I am, of
course, looking forward to NT5 here (with real symbolic links! Yes!)...
  I'm going to try and rebuild cygwin this evening and change the uname --
I'm not sure how hard that will be (it was easy in the B19 release). I think
I'll change the uname to return "CYGWIN_NT" or "CYGWIN32_NT" and the -r to
return "4.20.1".
  Also, I note that "mkdir junk/" fails, where as it seems to work just fine
on every other OS I've tried. I have to fix that because our software does
it a lot. Where do I send patches so that the maintainers of cygwin get
them? And what is the proper proceedure for making a patch file?

  BTW, I posted a recent problem i was having with multiple users -- two
different users logged into the same NT machine both running bash, and in
B19 I would get an instant crash -- access violation/exception. I've since
written a test program (a service, actually) that really stresses things. It
ran overnight on a B20.1 system with only one crash while on a B19 machine
it died on its first attempt. So I think that bug is fixed. Yes! Thank you
very much! [I do need to do a little more testing first to make sure on some
other machines].

  And the problem I'm having with a relative path in my PATH var seems to be
shared by some and not by others. I've been trying to assemble system
configurations to see if there is a crucial difference between the two sets
of systems, but haven't found it yet.

	Cheers,
		Gordon.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".