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 Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 9 Feb 2005 16:25:24 -0500 (EST) From: Glenn Fowler Message-Id: <200502092125.QAA94773@raptor.research.att.com> Organization: AT&T Research Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <407DF7D68DD30440B5CEB70ED234D1CF053F6C65 AT excuswa100 DOT americas DOT unity> <200502071836 DOT NAA41681 AT raptor DOT research DOT att DOT com> <20050209180158 DOT GA12456 AT cygbert DOT vinschen DOT de> To: cygwin AT cygwin DOT com Subject: Re: AT&T ksh93 On Wed, 9 Feb 2005 19:01:58 +0100 Corinna Vinschen wrote: > Glenn, > On Feb 7 13:36, Glenn Fowler wrote: > > I believe previous ksh93 vs. cygwin issues mentioned on this list have > > been addressed in this release. > > > > I won't be the cygwin ksh93 maintainer, but I can supply cygwin > > packages at the above URL to the maintainer, including any changes > > required in the package files. All of our packages, including the > > cygwin ones, are generated by table driven scripts, so any cygwin > > specific package changes will be rolled back into those tables and > > scripts. > I don't understand your problem with being Cygwin maintainer for this > package if you patch and build it anyway. The maintenance effort > besides building and packing looks pretty small to me. Package > specific questions on the Cygwin ML are not going into the millions > or so. Well, except for coreutils, perhaps :-) From past experience I don't want to be a point of contact for the cygwin mailing lists. > I had a look into the description on > http://www.research.att.com/sw/download/win32/ and I don't exactly > like what I see. If you think that you know bugs in Cygwin, why > don't you talk to us, instead of just creating a web page in which > you describe what's wrong in Cygwin from your point of view? There's > a cygwin-patches mailing list for ages. This web page helps nobody > and it's also sort of insulting since it implies that we would be > unreasonable when it comes to talking about changing Cygwin. Especially > since a lot of stuff is definitely not in the "right" or "wrong" category, > but in the "how to get it similar" category and when talking about "how to > get it similar", there's no such thing as ultimate correctness. I went a few rounds with the cygwin lists a while back. Karsten Fleischer volunteered to run some interference too (thanks Karsten.) We got to the point of Karsten offering to patch cygwin, and then questions arose about whether the patches would even be accepted, given mine and Karsten's relationship to UWIN. At that point I had already coded the cygwin system call intercepts and ksh93 and all of the other ast section 1 commands and scripts were running. So we decided to move on to other (non-cygwin) stuff. > http://www.research.att.com/sw/download/win32/ As far as the win32 url being insulting to cygwin: if there is anything technically wrong please point it out and I'll correct it. Otherwise its pretty much a statement of fact. cygwin and UWIN make choices about how far they go in emulating the unix API. Like you point out, there is no right or wrong in some of these choices. However, there are definitely consequences for the choices made. It is my opinion that any unix-like porting target should, modulo C source configure style tweaks, accept the unix paradigms that work on all of the other unix-like targets. In some instances cygwin goes counter to that opinion. I worked around those differences by modifying a library used by all ast applications, along with cygwin specific additions to the ast nmake compiler probe. Finally, I documented the workarounds in case anyone might have interest. > But of course it's your choice. I don't have to like it. I would > rather appreciate an open discussion on cygwin-patches (including > patches, maybe) or even on cygwin-developers, though. I stay on the user side of OS API's to maintain hacking sanity. I'll be happy to discuss details of the workarounds cited in the win32 url above. > For a start, I have one problem with your implementation. I don't think > it's appropriate for the shell to rename files on the fly, just because > the .exe suffix is missing, see your descriptions of chmod(2) and creat(2). One hack deserves another. How appropriate is it for cc -o t t.o to create t.exe instead of t? By not handling this at the system call level every script and application must be patched to handle ".exe or not .exe". Doing it in one spot allows ksh93 users to forget they're on a windows system -- that's my measure of "ultimate correctness". -- Glenn -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/