Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 <gsf AT research DOT att DOT com>
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> <cpv1b8$aki$1 AT sea DOT gmane DOT org> <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/