This is the mail archive of the cygwin@cygwin.com 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: ksh on cygwin


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@cygwin.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/


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