This is the mail archive of the cygwin 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: AT&T ksh93


Glenn,

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?

> > 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.

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.

> > 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.

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?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.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/


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