RE: Piping output from sqlplus

RE: Piping output from sqlplus

[Bakken, Luke]

> Why would ksh behave differently under Cygwin than under Solaris?

cygwin ksh is pdksh. The specific set of code you gave does not work in
pdksh. Read about it here:
http://web.cs.mun.ca/~michael/pdksh/

"Its weak points are that there are still a few differences from ksh88
(the major one is that `echo hi | read x' does not set x in the current
shell - the read is done in a separate process). See the NOTES file in
the distribution for more details."

You can get a Cygwin ksh from www.kornshell.com

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

Re: Piping output from sqlplus

[Chuck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bakken, Luke wrote:
|>Why would ksh behave differently under Cygwin than under Solaris?
|
|
| cygwin ksh is pdksh. The specific set of code you gave does not work in
| pdksh. Read about it here:
| http://web.cs.mun.ca/~michael/pdksh/
|
| "Its weak points are that there are still a few differences from ksh88
| (the major one is that `echo hi | read x' does not set x in the current
| shell - the read is done in a separate process). See the NOTES file in
| the distribution for more details."
|
| You can get a Cygwin ksh from www.kornshell.com
|

That explains it. I'll check out the one on www.kornshell.com. Thanks.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBwtgnzIf+rZpn0oQRAtz2AJ9Rz+JyRyZtn8MlPtlaXf0PXVQ4PgCggMzb
kq7eOjE1X4yPoZl09CuqeZU=
=45me
-----END PGP SIGNATURE-----


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

RE: Piping output from sqlplus

[Dave Korn]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Chuck
> Sent: 17 December 2004 12:59

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bakken, Luke wrote:
> |>Why would ksh behave differently under Cygwin than under Solaris?
> |
> |
> | cygwin ksh is pdksh. The specific set of code you gave does 
> not work in
> | pdksh. Read about it here:
> | http://web.cs.mun.ca/~michael/pdksh/
> |
> | "Its weak points are that there are still a few differences 
> from ksh88
> | (the major one is that `echo hi | read x' does not set x in 
> the current
> | shell - the read is done in a separate process). See the 
> NOTES file in
> | the distribution for more details."
> |
> | You can get a Cygwin ksh from www.kornshell.com
> |
> 
> That explains it. I'll check out the one on www.kornshell.com. Thanks.
> 


  At this stage of the proceedings it is traditional for me to have to explain
that I am no relation.... :)

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

Re: Piping output from sqlplus

[Chuck]

Bakken, Luke wrote:
>>Why would ksh behave differently under Cygwin than under Solaris?
> 
> 
> cygwin ksh is pdksh. The specific set of code you gave does not work in
> pdksh. Read about it here:
> http://web.cs.mun.ca/~michael/pdksh/
> 
> "Its weak points are that there are still a few differences from ksh88
> (the major one is that `echo hi | read x' does not set x in the current
> shell - the read is done in a separate process). See the NOTES file in
> the distribution for more details."
> 
> You can get a Cygwin ksh from www.kornshell.com
> 

This is working just perfectly thanks. I would like to note (for the 
archives) that this ksh does not support the -l option. If you want to 
use it for a login shell so that it runs /etc/profile and $HOME/.profile 
automatically, make a copy of it named -ksh and run that from your 
windows batch file. I tried just creating a symlink named -ksh first, 
but Windows didn't like it.


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

Re: Piping output from sqlplus

[Christopher Faylor]

On Fri, Dec 17, 2004 at 11:26:15AM -0500, Chuck wrote:
>Bakken, Luke wrote:
>>>Why would ksh behave differently under Cygwin than under Solaris?
>>
>>
>>cygwin ksh is pdksh. The specific set of code you gave does not work in
>>pdksh. Read about it here:
>>http://web.cs.mun.ca/~michael/pdksh/
>>
>>"Its weak points are that there are still a few differences from ksh88
>>(the major one is that `echo hi | read x' does not set x in the current
>>shell - the read is done in a separate process). See the NOTES file in
>>the distribution for more details."
>>
>>You can get a Cygwin ksh from www.kornshell.com
>>
>
>This is working just perfectly thanks. I would like to note (for the 
>archives) that this ksh does not support the -l option. If you want to 
>use it for a login shell so that it runs /etc/profile and $HOME/.profile 
>automatically, make a copy of it named -ksh and run that from your 
>windows batch file. I tried just creating a symlink named -ksh first, 
>but Windows didn't like it.

I'd like to note for the archives also that I'd like to get the real version
of ksh into the cygwin distribution.

This comes up from time to time.  The first time it happened someone was insisting
that they needed to change the Cygwin DLL for this to happen and I had reservations
about the licensing status of some of the changes since the person had also seen
U/WIN sources.  Then, somehow, ksh was built without the need to change cygwin and
a cygwin ksh package was going to show up any second now.

Well, years later, we still don't have a ksh.

Anyone want to take the plunge?

cgf

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

Re: Piping output from sqlplus

[Chuck]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Faylor wrote:
| On Fri, Dec 17, 2004 at 11:26:15AM -0500, Chuck wrote:
|
|>Bakken, Luke wrote:
|>
|>>>Why would ksh behave differently under Cygwin than under Solaris?
|>>
|>>
|>>cygwin ksh is pdksh. The specific set of code you gave does not work in
|>>pdksh. Read about it here:
|>>http://web.cs.mun.ca/~michael/pdksh/
|>>
|>>"Its weak points are that there are still a few differences from ksh88
|>>(the major one is that `echo hi | read x' does not set x in the current
|>>shell - the read is done in a separate process). See the NOTES file in
|>>the distribution for more details."
|>>
|>>You can get a Cygwin ksh from www.kornshell.com
|>>
|>
|>This is working just perfectly thanks. I would like to note (for the
|>archives) that this ksh does not support the -l option. If you want to
|>use it for a login shell so that it runs /etc/profile and $HOME/.profile
|>automatically, make a copy of it named -ksh and run that from your
|>windows batch file. I tried just creating a symlink named -ksh first,
|>but Windows didn't like it.
|
|
| I'd like to note for the archives also that I'd like to get the real
version
| of ksh into the cygwin distribution.
|
| This comes up from time to time.  The first time it happened someone
was insisting
| that they needed to change the Cygwin DLL for this to happen and I had
reservations
| about the licensing status of some of the changes since the person had
also seen
| U/WIN sources.  Then, somehow, ksh was built without the need to
change cygwin and
| a cygwin ksh package was going to show up any second now.
|
| Well, years later, we still don't have a ksh.
|
| Anyone want to take the plunge?
|
| cgf
|

I have come across one other problem with ksh'93 for Cygwin from
www.kornshell.com. It chokes on path names that don't follow the pure
unix convention. For example c:/oracle/ora92 causes problems but
/cygdrive/c/oracle/ora92 does not.

It doesn't like //server_name/share_name either.

I need a korn shell that will handle the windows-like path names
(pdksh),  and where "read" executes in the same shell that called it
(ksh '93).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFBwz7LzIf+rZpn0oQRAvIYAJjpbQtTNIbQ63Kt0Bd57jvlKbqHAKCbeReO
mCrlL3wnkpwOLpq0bb04OQ==
=ijjd
-----END PGP SIGNATURE-----


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

AT&T ksh93

[Glenn Fowler]

On 17 Dec 2004 16:35:31 -0000 Christopher Faylor wrote:

> I'd like to note for the archives also that I'd like to get the real version
> of ksh into the cygwin distribution.

> This comes up from time to time.  The first time it happened someone was insisting
> that they needed to change the cygwin DLL for this to happen and I had reservations
> about the licensing status of some of the changes since the person had also seen
> U/WIN sources.  Then, somehow, ksh was built without the need to change cygwin and
> a cygwin ksh package was going to show up any second now.

> Well, years later, we still don't have a ksh.

> Anyone want to take the plunge?

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.

-- Glenn Fowler -- AT&T Research, Florham Park NJ --


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

Re: AT&T ksh93

[Corinna Vinschen]

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@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/

Re: AT&T ksh93

[Glenn Fowler]

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/

Re: AT&T ksh93

[Dr. Volker Zell]

>>>>> Glenn Fowler writes:

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

Man pages should go to /usr/share/man in cygwin land.

    > -- Glenn Fowler -- AT&T Research, Florham Park NJ --

Ciao
  Volker


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

Re: AT&T ksh93

[Glenn Fowler]

On Thu, 10 Feb 2005 09:41:14 +0100 Dr. Volker Zell wrote:
> >>>>> Glenn Fowler writes:

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

> Man pages should go to /usr/share/man in cygwin land.

I reposted the 2005-02-02 binary tarball and md5 with
	usr/doc => usr/share/doc
	usr/man => usr/share/man
thanks


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

Re: AT&T ksh93

[Corinna Vinschen]

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/

Re: AT&T ksh93

[Glenn Fowler]

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/