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/

Re: Piping output from sqlplus

[Chuck]

Christopher Faylor wrote:
> On Mon, Dec 20, 2004 at 10:02:22AM -0500, Chuck wrote:
> 
>>Bakken, Luke wrote:
>>
>>>>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).
>>>
>>>Keep wishing. There are other ways of doing what you need to do with
>>>sqlplus without using a pipe and read.
>>
>>I have dozen's of ksh scripts already written and running on other 
>>platforms. I'm not going to change them all just to accomodate a 
>>weakness in Cygwin, or more precisely pdksh.
> 
> 
> So you've got dozens of ksh scripts and your method of getting them
> working on cygwin is to wish real hard that something changes?  You must
> not want to get things working on windows very much then.
> 

I don't really *need* them to work on Windows. I just thought I could 
use Cygwin to develop and maintain them while I'm on my laptop and not 
connected. The final destination of all my ksh scripts will be Solaris. 
That's where they need to run

I'll be able to live with the ksh from www.kornshell.com. It's closer to 
what Sun distributes.


--
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 Mon, Dec 20, 2004 at 10:02:22AM -0500, Chuck wrote:
>Bakken, Luke wrote:
>>>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).
>>
>>Keep wishing. There are other ways of doing what you need to do with
>>sqlplus without using a pipe and read.
>
>I have dozen's of ksh scripts already written and running on other 
>platforms. I'm not going to change them all just to accomodate a 
>weakness in Cygwin, or more precisely pdksh.

So you've got dozens of ksh scripts and your method of getting them
working on cygwin is to wish real hard that something changes?  You must
not want to get things working on windows very much then.

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

[Igor Pechtchanski]

On Mon, 20 Dec 2004, Chuck wrote:

> Bakken, Luke wrote:
> > > 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).
> >
> > Keep wishing. There are other ways of doing what you need to do with
> > sqlplus without using a pipe and read.
>
> I have dozen's of ksh scripts already written and running on other
> platforms. I'm not going to change them all just to accomodate a
> weakness in Cygwin, or more precisely pdksh.

Cygwin isn't the only platform where ksh is pdksh.  You can't change all
the platforms.  If you want your scripts to be truly portable, you should
try to accomodate the idiosyncracies of each platform.  As mentioned
above, it's rather easy to change the scripts so that they work on all
platforms (including Cygwin).  You can also test whether your construct
works, and if it doesn't, have a bit of pdksh-specific code.

Basically (again, as others mentioned), Cygwin's main ksh will stay pdksh
unless someone (i.e., you) packages and offers to maintain the "real" ksh.
If you decide to do this[*], please review the packaging instructions at
<http://cygwin.com/setup.html>, and good luck.  It might also help to
review the prior discussions on the issue (search the cygwin-apps archives
for ksh93).
	Igor
[*] You'll also need to coordinate with the pdksh maintainer (me)
regarding the naming of executables and symlink policies.  Such
coordination usually happens on the cygwin-apps mailing list (which all
maintainers have to read).  When you ITP the package, this will come up.
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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:
>>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).
> 
> 
> Keep wishing. There are other ways of doing what you need to do with
> sqlplus without using a pipe and read.
> 

I have dozen's of ksh scripts already written and running on other 
platforms. I'm not going to change them all just to accomodate a 
weakness in Cygwin, or more precisely pdksh.


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

[Bakken, Luke]

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

Keep wishing. There are other ways of doing what you need to do with
sqlplus without using a pipe and read.

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

[Buchbinder, Barry (NIH/NIAID)]

At Thursday, December 16, 2004 3:57 PM, Chuck wrote:
> 
> Buchbinder, Barry (NIH/NIAID) wrote:
>> At Thursday, December 16, 2004 3:29 PM, Chuck wrote:
>>> 
>>> I'm having a strange problem reading the output from sqlplus in
>>> Cygwin. Sqlplus is a windows command line program used to access
>>> oracle databases. My command looks something like this...
>>> 
>>> sqlplus -s <<! | read line
>>> user/password@database
>>> set pagesize 0 linesize 200 feedback off tab off
>>> select col1||chr(9)||col2
>>> from table;
>>> !
>>> 
>>> This should output one line to stdout with the two values separated
>>> by a tab character. The read command should read it into the
>>> variable $line. On my Solaris system it works perfectly. In Cygwin,
>>> $line is empty. 
>>> 
>>> If I remove the "read line", the output displays on the tty just
>>> fine. 
>>> 
>>> I though it might be related to the line end characters so I tried
>>> converting them with the dos2unix filter. Didn't work. Neither did
>>> tr -d \\r. Both ways, $line still ends up being empty.
>>> 
>>> If I replace the "read line" with "od -c" to dump the characters, it
>>> shows the one line as expected.
>>> 
>>> If I redirect the output to a file, the file contains one line as
>>> expected. 
>>> 
>>> If I try to read the output into a variable, I get an empty variable
>>> 
>>> Any ideas?
>> 
>> If the output shows up OK in a file, do
>> VAR="$(cat file)"
> 
> That may work but it misses the point. I'm writing a script and I want
> it to work on Cygwin and unix.
> 
> BTW the shell I'm using is ksh.

Well, I don't have access to a Unix or Linux machine, but I would have
thought outputting a file and filing the variable by cat'ting it would work
there, too.

I don't use ksh.  If what I suggested does not work there, something like
the following should.

VAR=`cat file`

If the trailing \n gets converted into an undesirable space, you could
always do

VAR=`cat file | tr -d '\n'`

--
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 Thu, Dec 16, 2004 at 03:29:16PM -0500, Chuck wrote:
|
|>I'm having a strange problem reading the output from sqlplus in Cygwin.
|>Sqlplus is a windows command line program used to access oracle
|>databases. My command looks something like this...
|>
|>sqlplus -s <<! | read line
|>user/password@database
|>set pagesize 0 linesize 200 feedback off tab off
|>select col1||chr(9)||col2
|
|>from table;
|
|>!
|>
|>This should output one line to stdout with the two values separated by a
|>tab character. The read command should read it into the variable $line.
|>On my Solaris system it works perfectly. In Cygwin, $line is empty.
|
|
| Just to demonstrate what you're seeing without the sqlplus requirement:
|
|   bash$ echo hello | read line
|   bash$ echo $line
|
|   bash$
|
| The reason for the behavior is apparently that when you use read in a
| pipe like this bash and ash fork a separate process so the variable only
| exists very briefly in that process and `line' is never defined in the
| main process.
|
| zsh does what you'd expect, so if you can use zsh instead of bash, that
| would be a solution.  Otherwise, you probably will have to experiment
| with setting IFS and using either $(sqlplus) or `sqlplus` .
|
| cgf
|

Actually I'm using ksh.

$ echo hello | read LINE
$ echo $LINE

$

Looks like you said. I know this is not the expectd behaviour for ksh
though. On Solaris ksh ...

Solaris$ echo hello | read LINE
Solaris$ echo $LINE
hello
Solaris$

Why would ksh behave differently under Cygwin than under Solaris?


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

iD8DBQFBwfYpzIf+rZpn0oQRAtnYAJ9jBdGzER29YzWnMOmREeQJv+fasQCdGFQc
jRPqneau2f7PFhDXtwKGsn4=
=bY4I
-----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

[Chuck]

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

Buchbinder, Barry (NIH/NIAID) wrote:
| At Thursday, December 16, 2004 3:29 PM, Chuck wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>I'm having a strange problem reading the output from sqlplus in
|>Cygwin. Sqlplus is a windows command line program used to access
|>oracle
|>databases. My command looks something like this...
|>
|>sqlplus -s <<! | read line
|>user/password@database
|>set pagesize 0 linesize 200 feedback off tab off
|>select col1||chr(9)||col2
|>from table;
|>!
|>
|>This should output one line to stdout with the two values separated
|>by a tab character. The read command should read it into the variable
|>$line.
|>On my Solaris system it works perfectly. In Cygwin, $line is empty.
|>
|>If I remove the "read line", the output displays on the tty just fine.
|>
|>I though it might be related to the line end characters so I tried
|>converting them with the dos2unix filter. Didn't work. Neither did tr
|>-d \\r. Both ways, $line still ends up being empty.
|>
|>If I replace the "read line" with "od -c" to dump the characters, it
|>shows the one line as expected.
|>
|>If I redirect the output to a file, the file contains one line as
|>expected.
|>
|>If I try to read the output into a variable, I get an empty variable
|>
|>Any ideas?
|
|
| If the output shows up OK in a file, do
| VAR="$(cat file)"
|

That may work but it misses the point. I'm writing a script and I want
it to work on Cygwin and unix.

BTW the shell I'm using is ksh.

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

iD8DBQFBwfaHzIf+rZpn0oQRAvKQAJ9WYJ6CbGrEeDwN9lMg2fzOIGsiOgCffjyz
BxriTOuv4IqT3zdFMHUesIY=
=jJGJ
-----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

[Buchbinder, Barry (NIH/NIAID)]

At Thursday, December 16, 2004 3:29 PM, Chuck wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm having a strange problem reading the output from sqlplus in
> Cygwin. Sqlplus is a windows command line program used to access
> oracle 
> databases. My command looks something like this...
> 
> sqlplus -s <<! | read line
> user/password@database
> set pagesize 0 linesize 200 feedback off tab off
> select col1||chr(9)||col2
> from table;
> !
> 
> This should output one line to stdout with the two values separated
> by a tab character. The read command should read it into the variable
> $line. 
> On my Solaris system it works perfectly. In Cygwin, $line is empty.
> 
> If I remove the "read line", the output displays on the tty just fine.
> 
> I though it might be related to the line end characters so I tried
> converting them with the dos2unix filter. Didn't work. Neither did tr
> -d \\r. Both ways, $line still ends up being empty.
> 
> If I replace the "read line" with "od -c" to dump the characters, it
> shows the one line as expected.
> 
> If I redirect the output to a file, the file contains one line as
> expected. 
> 
> If I try to read the output into a variable, I get an empty variable
> 
> Any ideas?

If the output shows up OK in a file, do
VAR="$(cat file)"

--
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 Thu, Dec 16, 2004 at 03:29:16PM -0500, Chuck wrote:
>I'm having a strange problem reading the output from sqlplus in Cygwin.
>Sqlplus is a windows command line program used to access oracle
>databases. My command looks something like this...
>
>sqlplus -s <<! | read line
>user/password@database
>set pagesize 0 linesize 200 feedback off tab off
>select col1||chr(9)||col2
>from table;
>!
>
>This should output one line to stdout with the two values separated by a
>tab character. The read command should read it into the variable $line.
>On my Solaris system it works perfectly. In Cygwin, $line is empty.

Just to demonstrate what you're seeing without the sqlplus requirement:

  bash$ echo hello | read line
  bash$ echo $line

  bash$

The reason for the behavior is apparently that when you use read in a
pipe like this bash and ash fork a separate process so the variable only
exists very briefly in that process and `line' is never defined in the
main process.

zsh does what you'd expect, so if you can use zsh instead of bash, that
would be a solution.  Otherwise, you probably will have to experiment
with setting IFS and using either $(sqlplus) or `sqlplus` .

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/

Piping output from sqlplus

[Chuck]

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

I'm having a strange problem reading the output from sqlplus in Cygwin.
Sqlplus is a windows command line program used to access oracle
databases. My command looks something like this...

sqlplus -s <<! | read line
user/password@database
set pagesize 0 linesize 200 feedback off tab off
select col1||chr(9)||col2
from table;
!

This should output one line to stdout with the two values separated by a
tab character. The read command should read it into the variable $line.
On my Solaris system it works perfectly. In Cygwin, $line is empty.

If I remove the "read line", the output displays on the tty just fine.

I though it might be related to the line end characters so I tried
converting them with the dos2unix filter. Didn't work. Neither did tr -d
\\r. Both ways, $line still ends up being empty.

If I replace the "read line" with "od -c" to dump the characters, it
shows the one line as expected.

If I redirect the output to a file, the file contains one line as expected.

If I try to read the output into a variable, I get an empty variable

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

iD8DBQFBwfAbzIf+rZpn0oQRAtcxAJ46XUAtR57DsuKAXj7nBFmR1V/QNQCfX/da
09U1qXkDrheltOlQrMSubzU=
=pQxI
-----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/