This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: AT&T ksh93
On Fri, 11 Feb 2005 11:21:07 +0100 Corinna Vinschen wrote:
> On Feb 9 16:25, Glenn Fowler wrote:
> > On Wed, 9 Feb 2005 19:01:58 +0100 Corinna Vinschen wrote:
> > > 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.
> Hmm, I have no idea what the problem was you had, but well, so be it.
> > 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
> That's the problem. It's not the problem that you're pointing out
> potential bugs in Cygwin, or if it's technical correct or incorrect.
> It's that you're pointing them out on some web page but don't inform us.
> The same situation is if I find potential bugs in ksh but decide not
> to tell you about them, but instead put them on some Cygwin web page.
> Whom does that help? Definitely not the ksh users, right?
been there, done that, informed, rejected, moved on
google "cygwin ksh fowler karsten site:cygwin.com"
there are 100's of messages in threads that go back to 2001-09
> > > 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.
> I would rather like to discuss them in the usual way. You write a mail
> to the Cygwin list describing a problem, then I flame you. No, that's
> not quite right. I'll look into it and we discuss this. Yes, that
> sounds better.
That would be fine.
> You might have seen the coreutils discussions and the perfect reports
> and testcases from Eric Blake. That's the best way to get problems
> fixed.
> Of course, that implies that you're interested in getting Cygwin
> fixed and so to reduce the need for the system call intercepts.
We had such interest way back.
It was successfully quashed.
We got our stuff working and moved on.
> > > 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".
> I see your point exactly. I'm far from being happy about the .exe
> handling in Cygwin but nevertheless, I'm wondering if it's appropriate
> for ksh to do it's own thing here. Regardless if the .exe handling
> is good or bad in Cygwin, I think that ksh should not behave very
> different from other shells running on Cygwin. What you do is a nice
> idea, but the difference would be surprising in a Cygwin environment.
We are at cross purposes here. Your goal is to make all applications
that run on cygwin act the same. The ast package goal (of which ksh
is a part) is to make ast applications act the same on all platforms.
> If I understand your change right, the following:
> $ cat foo.exe > bar
> would create a file "bar.exe" in ksh, but it would create a file "bar"
> in ash, bash, tcsh, and zsh. Do you see my point?
No. For the creat() intercept the conditions are that the created file
have exe magic *and* execute permission.
However, if the ksh builtin chmod were in scope (see the cygwin package
README) then a subsequent chmod +x bar would result in bar.exe. If
the intercepts are done right application code won't even be aware
of the underlying hackery.
Its all there in the astksh-20050202-src.tar.bz2 cygwin source package:
src/lib/libast/comp/omitted.c
src/lib/libast/features/omitted
These files could be the basis for further discussion w.r.t. ast vs. cygwin.
features/omitted is an iffe script that probes the cygwin.dll features
in question (.exe and a few others.)
> ... but the difference would be surprising in a Cygwin environment.
>From our experience the surprise would be that a unix shell script or
makefile worked without change on a windows system. There are a few
silent but savvy cygwin ast package users that have been working with
the ast intercept view of cygwin for 3 years or so with no complaints
(at least about the intercepts.)
Anyway, back to the ksh93 package topic, bottom line. We won't delete
the ast cygwin intercept code and add 100's of #ifdef __CYGWIN__ to
application code just so we can match cygwin.dll semantics. As cygwin.dll
evolves the features/omitted iffe script will compensate, up to
the point of disabling all intercepts.
--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/