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 19:01:58 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: AT&T ksh93 Message-ID: <20050209180158.GA12456@cygbert.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <407DF7D68DD30440B5CEB70ED234D1CF053F6C65 AT excuswa100 DOT americas DOT unity> <200502071836 DOT NAA41681 AT raptor DOT research DOT att DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502071836.NAA41681@raptor.research.att.com> User-Agent: Mutt/1.4.2i Glenn, On Feb 7 13:36, Glenn Fowler wrote: > Rather than waste time arguing about cygwin correctness, we added > section 2 system call intercepts to our base library to get cygwin to > act like unix. The library intercepts keep windows from contaminating > our mainline source and scripts. For details see > > http://www.research.att.com/sw/download/win32/ > > Since the last cygwin round AT&T ksh93, ast libraries, and UWIN source > and binaries have been released uder the OSI approved CPL 1.0 > (Common Public License 1.0.) I packaged the 2005-02-02 standalone > ksh for cygwin and posted setup.hint, tarballs and md5 sums at > > http://www.research.att.com/sw/download/beta/ > > The packages under this URL are password protected. See > > http://www.research.att.com/sw/download/faq.license.html > > for the rationale and name and password to use (the same name and > password for every user.) > > 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 :-) 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. 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. 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). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin AT cygwin DOT com Red Hat, Inc. -- 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/