Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Thu, 10 Jan 2002 14:45:51 +0100 From: Corinna Vinschen To: "'cygwin AT cygwin DOT com'" Subject: Re: ksh on cygwin Message-ID: <20020110144551.J12057@cygbert.vinschen.de> Mail-Followup-To: "'cygwin AT cygwin DOT com'" References: <200201101259 DOT g0ACxFN12728 AT dymwsm10 DOT mailwatch DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201101259.g0ACxFN12728@dymwsm10.mailwatch.com> User-Agent: Mutt/1.3.22.1i On Thu, Jan 10, 2002 at 07:59:12AM -0500, Fleischer, Karsten (K.) wrote: > It's a whole bunch of small fixes. I think I need to fill out the assignment form. Yeah, please send it as soon as possible since you'll have to send it by snail mail. Sometimes it takes two to three weeks for some reason. > Is it OK to send patches to 1.3.3-2 or should I move them to 1.3.6 first? I would suggest to move them to the latest from CVS. If you're always working against the latest from CVS you don't get hit too much by changes from other people. > I'll give a short summary of what I've fixed: I'll compare your below listing against current from CVS. You should evaluate my answers in that light. > - pathconf() doesn't check existance of the path It does. However, there's an error in _PC_PATH_MAX. It doesn't validate the incoming path which could result in a SEGV. I've checked in a fix. > - getpagesize() should return a value compatible with mmap(), that is dwAllocGranularity (65536) instead of dwPageSize (1024). We discussed that months ago. I think we're not going to change that (it's 4096, not 1024, btw.). It will result in dubious problems when a process mmaps a file. For instance, the latest gcc expects to be able to read over the end of an mmaped file if the size is not a multiple of getpagesize(). Now think of a file which is coincidentally exactly 1 page long... > - use .exe extension detection consequently in all syscalls You mean unlink() etc.? > - automatically add the .exe extension to a newly created file on close() when the first four bytes are 0x4d, 0x5a, 0x90, 0x00 (MS Executable magic bytes) and the file name didn't have an extension already. (This is from UWIN, I think it's really nice). Ugh. I'm not quite sure if I like that. > - exec*() functions would always invoke a /bin/sh on a file that isn't a valid executable. Only execlp()/execvp() should do so, others must return with an ENOEXEC. Sounds like a bug. > - the exec*() fix revealed a bug with vfork() in ash We have some vfork() changes in the meantime and even ash had an related error which should be fixed. > - use the contents of $SHELL instead of /bin/sh for execvp()/execlp() and system() (with some additional checks, e.g. do not use a csh, use only 'trusted' shells from /bin, /usr/bin, /usr/local/bin etc.). This allows the user to select his favorite shell manually, so no more "copy /bin/bash to /bin/sh" troubles. (This is also from UWIN). Hmm, interesting idea... > - some mmap() problems have been fixed. Since I have changed so much in mmap() you should actually first compare your changes to the current version. > - utime() doesn't mark st_ctime for update Really? I would never think so when inspecting the source code. > Does this sound OK for you, especially the UWIN things I'm mimicing? I don't like the idea to append a .exe suffix related to the first bytes in the file. But we can discuss everything, of course. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/