From: curtis AT pdi DOT com (Curtis Galloway)
Subject: Some bugs in b18
16 May 1997 08:07:35 -0700
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <337B1D2D.36F6BADD.cygnus.gnu-win32@pdi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.0b4 [en] (WinNT; I)
Original-To: gnu-win32 AT cygnus DOT com
X-Priority: 3 (Normal)
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Here are some problems I have come across so far in b18 that I haven't
seen reported elsewhere.

1. Problems with file permissions.  In winsup/winsup.h, STD_WBITS is
defined as only S_IWUSR.  This means that files that are not marked
read-only in the filesystem can never have 'group' or 'other' write
permission.  In my case, this ended up causing "test -w" to report that
a file was not writable when in fact it was.  (See below.)

Here's the diff to make 'other' and 'group' write permissions follow the
'owner' permission, as it did in b17.1:

*** winsup.h.00 Fri May 09 13:55:27 1997
--- winsup.h    Fri May 09 13:55:39 1997
***************
*** 388,394 ****
  #define alloca(x) __builtin_alloca (x)

  #define STD_RBITS S_IRUSR | S_IRGRP | S_IROTH
! #define STD_WBITS S_IWUSR
  #define STD_XBITS S_IXUSR | S_IXGRP | S_IXOTH

  #define O_NOSYMLINK 0x80000
--- 388,394 ----
  #define alloca(x) __builtin_alloca (x)

  #define STD_RBITS S_IRUSR | S_IRGRP | S_IROTH
! #define STD_WBITS S_IWUSR | S_IWGRP | S_IWOTH
  #define STD_XBITS S_IXUSR | S_IXGRP | S_IXOTH

  #define O_NOSYMLINK 0x80000

2. Problems with user ids.  If I don't have an /etc/passwd file, I get
very strange results.  For example:

  bash> whoami
  whoami: cannot find username for UID 500
  bash> touch foo
  bash> ls -l foo
  -rw-r--r--   1 544      everyone        0 May 15 07:11 foo

So am I userid 500 or 544?  This ambiguity causes "test -w" to fail
above, because I'm not the "owner" of the file, and I don't have write
permission.

3. Environment variables are uppercased.  Windows does the same thing
with environment variable names that it does with file names: it
preserves case, but it is not case sensitive.  In winsup/dcrt0.cc,
environment variable names are converted to uppercase to "prevent
confusion."

Unfortunately, this breaks many Win32 programs that expect to retrieve
environment variables by the name under which they are stored in the
registry.  The right approach, I think, is to make retrieval of
environment variables ignore case, as Windows does.  The second best
approach is not to uppercase environment variables retrieved from
Win32.  Here's the diff to implement that:

*** dcrt0.cc.00 Wed May 14 11:33:44 1997
--- dcrt0.cc    Thu May 15 07:20:35 1997
***************
*** 445,450 ****
--- 445,451 ----
        }
      (*u->envptr)[n] = 0;

+ #ifdef NEVER
      /* Amazingly, NT has a case sensitive environment name list,
         only sometimes.
         eg, it's normal to have NT set your "Path" to something.
***************
*** 460,465 ****
--- 461,467 ----
          if (islower (*p))
            *p = toupper (*p);
        }
+ #endif

      /* If we're using posix paths, we do a special thing for the PATH
         [and potentially others].  They might be in native format so we
turn

4. Terminal support.  The ncurses library does work, but not if you
change the default console window settings.  If you have a different
background and foreground color set, they are ignored, and if you have
the scrollback buffer turned on, you get very strange behavior.

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