RE: ksh on cygwin

RE: ksh on cygwin

[Fleischer, Karsten (K.)]

> > All other patches are bug fixes or small corrections to 
> make Cygwin behave more consistent.
> 
> Yeah, I was talking only about AST related stuff.  If a patch
> has nothing to do with AST, go ahead.  But be aware that we will
> discuss it and it still could be rejected, of course.  That's
> one of the most frustrating situations when contributing to an
> OSS project for the first time but we all had to go through it.

It's not the first time I'm contributing to a project, but the first time to Cygwin.

> > Are the issues cleared now?
> 
> It would be good if *you* are thinking they are cleared.  If you're
> feeling to move on thin ice with one of your patches, just hold this
> part back.  Please understand, we *want* to trust our contributors.

For me everything's clear now. The only offending patch is the $SHELL thing, which I'll be leaving out.
I'll start moving my patches to the latest CVS sources tomorrow.

Karsten

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: KSH on Cygwin

[Eric De Mund]

Folks,

Corinna Vinschen:
] What I don't quite get is: Is there actually any important feature in
] ksh which isn't already available in bash/tcsh/zsh?

There may be external considerations that trump feature considerations
(given that none of these shells is a drop-in replacement for ksh). Some
production hosts at some sites, or some hosts at government sites have
prohibitions against contrib software being installed on them. The
Solaris 2.6 production hosts at one former client of mine were
restricted in this way.

Shell scripts on these hosts were either ksh, csh, or sh scripts. If the
engineer wanted/needed to do a quick and dirty test of their ksh script
on a cygwin box on their desks, say, then first converting their script
to bash, tcsh, or zsh wouldn't be useful. (The client in question did
have a separate Solaris 2.6 development host, yet the above point is, I
hope, still valid.)

Regards,
Eric

May you dance like no one is subject to <http://docs.yahoo.com/info/terms/>.
--
Eric De Mund <ead@ixian.com> | Ixian Systems, Inc. | 53 49 B2 23 AF 6C 20 81
http://www.ixian.com/ead/    | Mountain View, CA   | ED DD 4C 81 AA C9 D1 A5

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

KSH on Cygwin

[Joshua Elson]

I apologize in advance if I've missed an obvious resource or if this question is off-topic for Cygwin (flame or ignore as appropriate).  With the recent KSH emails, I decided to try to get KSH running under Cygwin.

With emails of pre-compiled binaries for Cygwin and that KSH should compile OOB with Cygwin, I downloaded the INIT and ast-ksh packages for Cygwin and placed them in /tmp/ksh/lib/package/tgz.  I extracted the INIT tarball and then ran bin/package read.  The bin/package read command runs a bit and extracts some files but hangs when it gets to bin/package.  Apparently part of that script renames bin/package to bin/package.old and then gets stuck in some sort of loop (at least I can't tell what it's doing).  This behavior occurs with Cygwin specific packages as well as with the source for INIT and ast-ksh.

Any pointers are appreciated.
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: KSH on Cygwin

[Jon LaBadie]

On Fri, Jun 14, 2002 at 04:23:40PM -0500, Joshua Elson wrote:
> I apologize in advance if I've missed an obvious resource or if this question is off-topic for Cygwin (flame or ignore as appropriate).  With the recent KSH emails, I decided to try to get KSH running under Cygwin.
> 
> With emails of pre-compiled binaries for Cygwin and that KSH should compile OOB with Cygwin, I downloaded the INIT and ast-ksh packages for Cygwin and placed them in /tmp/ksh/lib/package/tgz.  I extracted the INIT tarball and then ran bin/package read.  The bin/package read command runs a bit and extracts some files but hangs when it gets to bin/package.  Apparently part of that script renames bin/package to bin/package.old and then gets stuck in some sort of loop (at least I can't tell what it's doing).  This behavior occurs with Cygwin specific packages as well as with the source for INIT and ast-ksh.

Here is what I did.  Originally with the 3/?? versions, then with the
6/14/2002 versions.  It is very similar to what you did, but it worked :)

Download the INIT and either ast-ksh, ast-base, or ast-open for cygwin.
The three ast-* packages differ in the number of executable's included
in the packages, from about 5 in ast-ksh to over 100 in ast-open.  Many
of the latter have counterparts in cygwin's /bin (ex chmod, ls, ...).

I put the downloaded *.tgz files in /tmp and used an empty directory
/tmp/ast for extraction.  The INIT package was extracted as you did,
creating bin, lib, arch, and ???.  Leaving the other package in /tmp,
I then ran bin/package read /tmp/ast-????*, i.e. mentioning the package
by its pathname.

Using the 6/14 versions, the above "read" succeeded for me with any of
the 3 ast-* packages, as long as I only read one of them.  Sometimes,
when I tried to read 2 or 3 of the ast-* packages, one after the other,
or tried to "reread" a package, I got a hang much like you describe.

A successful "read" extracts the ast-* package under arch/cygwin/*.
Created are bin, lib, man, fun (ksh functions) and other dirs.

For a while I just copied a couple of the cmds under
/tmp/ast/arch/cygwin/bin to /bin.  ksh seemed to work fine this way.

Later I decided to load the entire ast-open package on my system.
After extracting it in /tmp/ast/arch/cygwin, I moved all the subdirs
under /ast.  Now I include /ast/bin in my PATH.

HTH
-- 
Jon H. LaBadie                  jcyg@jgcomp.com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: KSH on Cygwin

[Thomas Baker]

I eventually managed to download the pdksh available from
the announcement section of http://cygwin.com, but after
gunzipping it and putting the ksh.exe into a bin directory
(and trying various other variations), I always got "Permission
denied." messages.  So I tried Jon's instructions for installing
the AST KSH (see below).

Following these instructions worked for me, though the
experience was marred aesthetically by little error messages
that flashed across the screen and scrolled away before I
could examine them in detail (eg, chmod could not deal with
the file named '----- README etc etc')

And the AST KSH seems to work now, though I now also have
all of the following files in addition:

/ast/bin/.paths
/ast/bin/ksh                       - plus some DLL files, plus a dozen or so other files
/ast/fun/dirs                      - plus popd, pushd
/ast/include/ast/align.h           - plus 93 more
/ast/include/prototyped.h
/ast/lib/file/magic
/ast/lib/lib/ast                   - plus 7 more files
/ast/lib/libast.dll.a              - plus 3 more
/ast/lib/make/MSGFUN.mk            - plus 4 more files
/ast/lib/package/gen/ast-ksh.ins   - plus 9 more files
/ast/lib/package/LICENSES/ast
/ast/lib/probe/C/probe
/ast/man/man1/sh.1
/ast/man/man3/ast.3                - plus 54 more files

All of this unexplained extra baggage makes me uneasy -- more
potential sources of conflict with existing resources...

Following Jon's advice, I put /ast/bin into my PATH, where
it picks up /ast/bin/ksh.  However, /usr/bin/man did not pick
up the /ast/man/man1 pages.  Moreover, the man page is here named
"sh.1" not (as "ksh.1" as I would have expected).  The command
"cp /ast/man/man1/sh.1 /usr/man/man1/ksh.1" fixed this, so that
I can run "man ksh" and get a result (along with a warning about
special character dg), but the man page actually says it is for
sh, so maybe this is not a ksh page after all??

I was then able to port an important old Korn shell of mine
from the MKS to the Cygwin environment (once I had changed
every #!e:/mks/mksnt/sh.exe to #!/usr/bin/ksh and every egrep
to grep -E).  However, an old KSH script of mine runs more
than three times more slowly under Cygwin than under MKS
(23 versus 7 seconds).

Okay, the KSH seems to be working under Cygwin at last,
but I'm not sure what I gain with the slower execution; the
extra binaries and related baggage; and the dodgy man page.
A simple Cygwin setup option that installs a binary and a
man page would have been less confusing.

Tom

On Sun, Jun 16, 2002 at 02:13:22AM -0400, Jon LaBadie wrote:
> Here is what I did.  Originally with the 3/?? versions, then with the
> 6/14/2002 versions.  It is very similar to what you did, but it worked :)
> 
> Download the INIT and either ast-ksh, ast-base, or ast-open for cygwin.
> The three ast-* packages differ in the number of executable's included
> in the packages, from about 5 in ast-ksh to over 100 in ast-open.  Many
> of the latter have counterparts in cygwin's /bin (ex chmod, ls, ...).
> 
> I put the downloaded *.tgz files in /tmp and used an empty directory
> /tmp/ast for extraction.  The INIT package was extracted as you did,
> creating bin, lib, arch, and ???.  Leaving the other package in /tmp,
> I then ran bin/package read /tmp/ast-????*, i.e. mentioning the package
> by its pathname.
> 
> Using the 6/14 versions, the above "read" succeeded for me with any of
> the 3 ast-* packages, as long as I only read one of them.  Sometimes,
> when I tried to read 2 or 3 of the ast-* packages, one after the other,
> or tried to "reread" a package, I got a hang much like you describe.
> 
> A successful "read" extracts the ast-* package under arch/cygwin/*.
> Created are bin, lib, man, fun (ksh functions) and other dirs.
> 
> For a while I just copied a couple of the cmds under
> /tmp/ast/arch/cygwin/bin to /bin.  ksh seemed to work fine this way.
> 
> Later I decided to load the entire ast-open package on my system.
> After extracting it in /tmp/ast/arch/cygwin, I moved all the subdirs
> under /ast.  Now I include /ast/bin in my PATH.

-- 
Dr. Thomas Baker                                Thomas.Baker@bi.fhg.de
Institutszentrum Schloss Birlinghoven          mobile +49-171-408-5784
Fraunhofer-Gesellschaft                          work +49-30-8109-9027
53754 Sankt Augustin, Germany                     fax +49-2241-14-2619

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: KSH on Cygwin

[Thomas Baker]

On Mon, Jun 17, 2002 at 03:08:37PM +0200, Thomas Baker wrote:
> Okay, the KSH seems to be working under Cygwin at last,
> but I'm not sure what I gain with the slower execution; the
> extra binaries and related baggage; and the dodgy man page.
> A simple Cygwin setup option that installs a binary and a
> man page would have been less confusing.

For the record, I did not intend to sound negative about
Cygwin here... -- the Cygwin phenomenon is amazing, and of
course patience is required...

I have been looking forward to KSH in particular, because
that is what it will take for me to move completely from MKS
Toolkit to Cygwin.  When I first installed Cygwin on the same
machine as MKS they clashed with each other and it took alot of
mailing-list searches to discover exactly what was happening
and to disentangle them (one problem was terminal-oriented
environment variables).  I have had to switch back and forth
between different-colored windows running MKS and Cygwin to run
particular commands, but a running KSH now makes it possible
to move the rest over to Cygwin.

For a non-techie like myself, however, the extra effort
involved in dealing with the extra baggage of the AST package
really adds up, so I humbly suggest that a Cygwin setup
package for KSH would be desirable as well.

Tom

-- 
Dr. Thomas Baker                                Thomas.Baker@bi.fhg.de
Institutszentrum Schloss Birlinghoven          mobile +49-171-408-5784
Fraunhofer-Gesellschaft                          work +49-30-8109-9027
53754 Sankt Augustin, Germany                     fax +49-2241-14-2619

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: KSH on Cygwin

[Corinna Vinschen]

On Tue, Jun 18, 2002 at 01:41:28PM +0200, Thomas Baker wrote:
> I have been looking forward to KSH in particular, because
> that is what it will take for me to move completely from MKS
> Toolkit to Cygwin.  When I first installed Cygwin on the same

What I don't quite get is:  Is there actually any important
feature in ksh which isn't already available in bash/tcsh/zsh?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: KSH on Cygwin

[Thomas Baker]

On Tue, Jun 18, 2002 at 03:10:01PM +0200, Corinna Vinschen wrote:
> On Tue, Jun 18, 2002 at 01:41:28PM +0200, Thomas Baker wrote:
> > I have been looking forward to KSH in particular, because
> > that is what it will take for me to move completely from MKS
> > Toolkit to Cygwin.  When I first installed Cygwin on the same
> 
> What I don't quite get is:  Is there actually any important
> feature in ksh which isn't already available in bash/tcsh/zsh?

I wrote a two-page script in KSH about eight years ago and
still depend on it on a daily basis for my work.  When I
try simply changing the #! line to bash I get error messages
suggesting that bash lacks certain features or expresses them
in another syntax.  I am not a programmer, just an amateur
shell-script writer, and do not have the time to solve these
various problems.  For all I know, a real shell expert could
port the script in twenty minutes; I wouldn't know.

One KSH-specific construct, I believe, is "print -u3"
to park some output in a buffer with the handle "3".

Tom

-- 
Dr. Thomas Baker                                Thomas.Baker@bi.fhg.de
Institutszentrum Schloss Birlinghoven          mobile +49-171-408-5784
Fraunhofer-Gesellschaft                          work +49-30-8109-9027
53754 Sankt Augustin, Germany                     fax +49-2241-14-2619

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: KSH on Cygwin

[Nicholas Wourms]

Ok,

I think it is important to note that there is *already* an individual who
is going to release KSH93 properly packaged and deployable by setup.exe. 
Patience is the key here, if you read some previous messages it was
pointed out that it should be done within the next couple of weeks as of
about a week ago.  As for what it has over Bash&Friends, I'll leave that
to a more fanatic KSH user to explain.

Cheers,
Nicholas

--- Thomas Baker <thomas.baker@bi.fhg.de> wrote:
> On Tue, Jun 18, 2002 at 03:10:01PM +0200, Corinna Vinschen wrote:
> > On Tue, Jun 18, 2002 at 01:41:28PM +0200, Thomas Baker wrote:
> > > I have been looking forward to KSH in particular, because
> > > that is what it will take for me to move completely from MKS
> > > Toolkit to Cygwin.  When I first installed Cygwin on the same
> > 
> > What I don't quite get is:  Is there actually any important
> > feature in ksh which isn't already available in bash/tcsh/zsh?
> 
> I wrote a two-page script in KSH about eight years ago and
> still depend on it on a daily basis for my work.  When I
> try simply changing the #! line to bash I get error messages
> suggesting that bash lacks certain features or expresses them
> in another syntax.  I am not a programmer, just an amateur
> shell-script writer, and do not have the time to solve these
> various problems.  For all I know, a real shell expert could
> port the script in twenty minutes; I wouldn't know.
> 
> One KSH-specific construct, I believe, is "print -u3"
> to park some output in a buffer with the handle "3".
> 
> Tom


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: KSH on Cygwin

[Jon LaBadie]

On Tue, Jun 18, 2002 at 03:10:01PM +0200, Corinna Vinschen wrote:
> On Tue, Jun 18, 2002 at 01:41:28PM +0200, Thomas Baker wrote:
> > I have been looking forward to KSH in particular, because
> > that is what it will take for me to move completely from MKS
> > Toolkit to Cygwin.  When I first installed Cygwin on the same
> 
> What I don't quite get is:  Is there actually any important
> feature in ksh which isn't already available in bash/tcsh/zsh?

Important is, of course, in the eye of the beholder.

I for one would not use tcsh or zsh.  I use bash under cygwin
rather than pdksh.  But that is only because ksh is not available.
In all other environments ksh is my default.  That is the main
importance of having it available under cygwin (to me).

As to explicit features lacking in bash (and/or others) I might include:

	floating point math
	non-posix functions with local environments
	a function PATH variable
	several special substitution capabilities like ${!array[*]}
	  which lists the current subscripts of array

Any proficient bash programmer may be able to point out my errors and
list lots of things bash has that ksh lacks.  And probably several will :(

-- 
Jon H. LaBadie                  jcyg@jgcomp.com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Fleischer, Karsten (K.)]

> If we just left out that patch we won't have a problem.

OK.

> > Two other patches mimic UWIN behavior. That can not be a 
> problem, since Cygwin also has adopted the UWIN symbolics links.
> 
> Mimicing isn't a problem as long as you didn't look into the
> sources and get the idea from there.  If you just looked how
> it works from examining the behaviour of the binaries, that's
> ok.

Again, I cannot have had a look into the sources. They are not available to the public.
I got the ideas
a) from the UWIN mailing list (the add .exe on close patch, see http://www.research.att.com/lists/uwin-users/2001/08/msg00043.html)
b) from playing with the binaries (rename() and link() logic)

Glenn and David commented a bit on those on request. Their comments were something like: "Don't add the .exe extension to "b" on rename("a.exe", "b")! Specifying an .exe extension indicates that the users knows what he's doing." [I had first added .exe to b, because I thought UWIN was wrong in this case.]
Again, no code and not even implementation details.
I believe that wouldn't have helped me either, as I don't know their underlying data structures and they do not know Cygwin's.
I've invented my own implementations.
There are no other UWIN related patches than those.
All other patches are bug fixes or small corrections to make Cygwin behave more consistent.

> > I found something interesting in the archives, see 
> http://www.cygwin.com/ml/cygwin/2001-02/msg00417.html. He 
> didn't need a release from AT&T, did he?
> > 
> 
> There's a difference.  He didn't contribute to Cygwin beyond
> May 2000 and his contributions weren't AST or U/Win related
> at all.

I was just trying to be picky :-)

> Licensing issues are really a big *@#$ but we have to be careful.
> We may not even take any code which smells GPL.  It would infect
> the Cygwin Library License.  For that reason we're most happy
> about completely self-written code or copies/ports of BSD licensed
> source.

Are the issues cleared now?

Karsten

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Fri, Jan 11, 2002 at 09:50:50AM -0500, Fleischer, Karsten (K.) wrote:
> > If we just left out that patch we won't have a problem.
> 
> OK.
> 
> > > Two other patches mimic UWIN behavior. That can not be a 
> > problem, since Cygwin also has adopted the UWIN symbolics links.
> > 
> > Mimicing isn't a problem as long as you didn't look into the
> > sources and get the idea from there.  If you just looked how
> > it works from examining the behaviour of the binaries, that's
> > ok.
> 
> Again, I cannot have had a look into the sources. They are not available to the public.
> [...]
> All other patches are bug fixes or small corrections to make Cygwin behave more consistent.

Yeah, I was talking only about AST related stuff.  If a patch
has nothing to do with AST, go ahead.  But be aware that we will
discuss it and it still could be rejected, of course.  That's
one of the most frustrating situations when contributing to an
OSS project for the first time but we all had to go through it.

> > Licensing issues are really a big *@#$ but we have to be careful.
> > We may not even take any code which smells GPL.  It would infect
> > the Cygwin Library License.  For that reason we're most happy
> > about completely self-written code or copies/ports of BSD licensed
> > source.
> 
> Are the issues cleared now?

It would be good if *you* are thinking they are cleared.  If you're
feeling to move on thin ice with one of your patches, just hold this
part back.  Please understand, we *want* to trust our contributors.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Fleischer, Karsten (K.)]

> And, I'm sorry but it really looks to me like you'd need a 
> release from
> AT&T indicating that any patches you provided to us are 
> unemcumbered by
> this license.  I don't see how you can sign away the rights to any
> patches that you make if you have been working on code that is covered
> by this license.

Actually, having reviewed my patches, it's only patch based on AST - the $SHELL patch.
I'm imitating the AST function pathshell() there.
Now, since Corinna has made clear to me that there's no real super user on Cygwin, half of the patch is nonsense anyway and can be removed.

Two other patches mimic UWIN behavior. That can not be a problem, since Cygwin also has adopted the UWIN symbolics links.

I found something interesting in the archives, see http://www.cygwin.com/ml/cygwin/2001-02/msg00417.html. He didn't need a release from AT&T, did he?


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Fri, Jan 11, 2002 at 08:53:07AM -0500, Fleischer, Karsten (K.) wrote:
> > And, I'm sorry but it really looks to me like you'd need a 
> > release from
> > AT&T indicating that any patches you provided to us are 
> > unemcumbered by
> > this license.  I don't see how you can sign away the rights to any
> > patches that you make if you have been working on code that is covered
> > by this license.
> 
> Actually, having reviewed my patches, it's only patch based on AST - the $SHELL patch.
> I'm imitating the AST function pathshell() there.
> Now, since Corinna has made clear to me that there's no real super user on Cygwin, half of the patch is nonsense anyway and can be removed.

If we just left out that patch we won't have a problem.
> 
> Two other patches mimic UWIN behavior. That can not be a problem, since Cygwin also has adopted the UWIN symbolics links.

Mimicing isn't a problem as long as you didn't look into the
sources and get the idea from there.  If you just looked how
it works from examining the behaviour of the binaries, that's
ok.

> I found something interesting in the archives, see http://www.cygwin.com/ml/cygwin/2001-02/msg00417.html. He didn't need a release from AT&T, did he?
> 

There's a difference.  He didn't contribute to Cygwin beyond
May 2000 and his contributions weren't AST or U/Win related
at all.

Licensing issues are really a big *@#$ but we have to be careful.
We may not even take any code which smells GPL.  It would infect
the Cygwin Library License.  For that reason we're most happy
about completely self-written code or copies/ports of BSD licensed
source.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Fri, Jan 11, 2002 at 08:53:07AM -0500, Fleischer, Karsten (K.) wrote:
>> And, I'm sorry but it really looks to me like you'd need a 
>> release from
>> AT&T indicating that any patches you provided to us are 
>> unemcumbered by
>> this license.  I don't see how you can sign away the rights to any
>> patches that you make if you have been working on code that is covered
>> by this license.
>
>Actually, having reviewed my patches, it's only patch based on AST -
>the $SHELL patch.  I'm imitating the AST function pathshell() there.
>Now, since Corinna has made clear to me that there's no real super user
>on Cygwin, half of the patch is nonsense anyway and can be removed.

So, we've all agreed that we don't want those patches.

I also am not interested in any of the "automatically add .exe" patches.
We've been over this ground many times in the past.

Sorry.

>Two other patches mimic UWIN behavior.  That can not be a problem,
>since Cygwin also has adopted the UWIN symbolics links.
>
>I found something interesting in the archives, see
>http://www.cygwin.com/ml/cygwin/2001-02/msg00417.html.  He didn't need
>a release from AT&T, did he?

You know, I was waiting for that.  The patterns are so predictable it's
scary.  I think this whole free will thing that is so much bally hooed is
really just a crock.

The cygwin mailing list is replete with Pavlovian responses.  Person has
problem installing.  Person immediately fires off standard email to
cygwin@cygwin.com.

cgf says blah, person responds blech.  There is never any variation.

In this case, I'm trying to be careful about licensing, so scurry,
scurry, scurry, Aha! Here's a potential case (maybe) where cgf *wasn't*
careful.  I'll trip him up now!

I don't know why you found this exercise useful or what your expected
response was other than to irritate.  If that was the expected response,
you succeeded.

Anyway, if you don't think that your patches are encumbered then, that's
ok with me.  Send in a release to Red Hat.  Make sure that you also have
a release from your employer if you are not self-employed.  I would *really*
like to get something official from AT&T if you were actually working for
them, too.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Karsten Fleischer]

> I would *really* like to get something official from AT&T if you were
> actually working for them, too.

OK, I triggered this.
I'll be quiet now.

Karsten

P.S.: I gave you some clues about real bugs in Cygwin. Maybe someone else
could have a look at those.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Sat, Jan 12, 2002 at 12:54:17AM +0100, Karsten Fleischer wrote:
>>I would *really* like to get something official from AT&T if you were
>>actually working for them, too.
>
>OK, I triggered this.  I'll be quiet now.

I'm just asking for assurances.

Can you get someone from AT&T to send email here saying that they have
no interest in your changes?  That + your assignment will be enough for
me.

>P.S.: I gave you some clues about real bugs in Cygwin. Maybe someone else
>could have a look at those.

Your original email mentions these bugs:

>- pathconf() doesn't check existance of the path

I think Corinna fixed this.

>- getpagesize() should return a value compatible with mmap(), that is
>dwAllocGranularity (65536) instead of dwPageSize (1024).

Corinna explained the rationale here.

>- exec*() functions would always invoke a /bin/sh on a file that isn't
>a valid executable.  Only execlp()/execvp() should do so, others must
>return with an ENOEXEC.

Valid bug.

>- the exec*() fix revealed a bug with vfork() in ash

Don't know what this is.

>- some mmap() problems have been fixed.

Don't know what these are.

>- utime() doesn't mark st_ctime for update

I assume that this is a valid bug.

If we can work out the above licensing issues then patches for these
would be great.  Otherwise more details for the "Don't know" problems
would allow us to fix the problems.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Karsten Fleischer]

> I'm just asking for assurances.
>
> Can you get someone from AT&T to send email here saying that they have
> no interest in your changes?  That + your assignment will be enough for
> me.

Glenn Fowler and David Korn will prepare a message. Is that OK? Or must an
AT&T lawyer be involved?

Karsten


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Tue, Jan 15, 2002 at 05:45:16PM +0100, Karsten Fleischer wrote:
>> I'm just asking for assurances.
>>
>> Can you get someone from AT&T to send email here saying that they have
>> no interest in your changes?  That + your assignment will be enough for
>> me.
>
>Glenn Fowler and David Korn will prepare a message. Is that OK? Or must an
>AT&T lawyer be involved?

As long as the person thinks they have the right to send the message, I'm happy.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Karsten Fleischer]

> As long as the person thinks they have the right to send the
> message, I'm happy.

They have the right. Everything should be cleared tomorrow. Can I fax you
the assignment form?

Karsten


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Wed, Jan 16, 2002 at 01:47:01AM +0100, Karsten Fleischer wrote:
>> As long as the person thinks they have the right to send the
>> message, I'm happy.
>
>They have the right. Everything should be cleared tomorrow. Can I fax you
>the assignment form?

It doesn't go to me.  Please send it to the address mentioned on the assignment
page.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Karsten Fleischer]

> >They have the right. Everything should be cleared tomorrow. Can I fax you
> >the assignment form?
> 
> It doesn't go to me.  Please send it to the address mentioned on 
> the assignment
> page.

OK, I'll snail it.

Karsten

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Fleischer, Karsten (K.)]

> If you've actually looked at the UWIN sources, this is not 
> enough.  IANAL
> either, but I believe that this means you've been tainted.  That means
> that we can't use your patches.  Sorry.

I've never had the chance to look at the UWIN sources. It's proprietary.
As I said before, the UWIN developers explained the concepts verbally to me, no source code involved.

The AST tools and libraries, which form the basis for the UWIN _tools_ (not the UNIX emulation itself) are open source. I rewritten some things from those sources (but from memory).

> I hope I am misinterpreting what you said incorrectly...

:-P

Karsten

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 11:18:04AM -0500, Fleischer, Karsten (K.) wrote:
>>If you've actually looked at the UWIN sources, this is not enough.
>>IANAL either, but I believe that this means you've been tainted.  That
>>means that we can't use your patches.  Sorry.
>
>I've never had the chance to look at the UWIN sources.  It's
>proprietary.  As I said before, the UWIN developers explained the
>concepts verbally to me, no source code involved.
>
>The AST tools and libraries, which form the basis for the UWIN _tools_
>(not the UNIX emulation itself) are open source.  I rewritten some
>things from those sources (but from memory).
>
>>I hope I am misinterpreting what you said incorrectly...
>
>:-P

I'm not sure but I don't think it matters if the sources are
proprietary.  Maybe this is getting incredibly picky but if you adapted
algorithms from other non-GPL compliant programs then that is probably
an issue, too.

This wouldn't be an issue for the Berkeley license, though.  I don't know
what the AST tools use for licensing.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 01:40:19PM -0500, Christopher Faylor wrote:
>On Thu, Jan 10, 2002 at 11:18:04AM -0500, Fleischer, Karsten (K.) wrote:
>>>If you've actually looked at the UWIN sources, this is not enough.
>>>IANAL either, but I believe that this means you've been tainted.  That
>>>means that we can't use your patches.  Sorry.
>>
>>I've never had the chance to look at the UWIN sources.  It's
>>proprietary.  As I said before, the UWIN developers explained the
>>concepts verbally to me, no source code involved.
>>
>>The AST tools and libraries, which form the basis for the UWIN _tools_
>>(not the UNIX emulation itself) are open source.  I rewritten some
>>things from those sources (but from memory).
>>
>>>I hope I am misinterpreting what you said incorrectly...
>>
>>:-P
>
>I'm not sure but I don't think it matters if the sources are
>proprietary.  Maybe this is getting incredibly picky but if you adapted
>algorithms from other non-GPL compliant programs then that is probably
>an issue, too.
>
>This wouldn't be an issue for the Berkeley license, though.  I don't know
>what the AST tools use for licensing.

FWIW, I'm checking on this internally now.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Karsten Fleischer]

> FWIW, I'm checking on this internally now.

Please do so.

Karsten

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Fri, Jan 11, 2002 at 02:03:44AM +0100, Karsten Fleischer wrote:
>> FWIW, I'm checking on this internally now.
>
>Please do so.

I will.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Karsten Fleischer]

> I'm not sure but I don't think it matters if the sources are
> proprietary.  Maybe this is getting incredibly picky but if you adapted
> algorithms from other non-GPL compliant programs then that is probably
> an issue, too.

I don't know if something like "If the first four bytes of a file are
'poop', then hold your breath" is considered an algorithm.
I've contacted Glenn Fowler regarding this issue.
He'll confirm what I've said.

> This wouldn't be an issue for the Berkeley license, though.  I don't know
> what the AST tools use for licensing.

OK, once again:
http://www.research.att.com/sw/license/ast-open.html

Karsten


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Fri, Jan 11, 2002 at 02:03:43AM +0100, Karsten Fleischer wrote:
>> I'm not sure but I don't think it matters if the sources are
>> proprietary.  Maybe this is getting incredibly picky but if you adapted
>> algorithms from other non-GPL compliant programs then that is probably
>> an issue, too.
>
>I don't know if something like "If the first four bytes of a file are
>'poop', then hold your breath" is considered an algorithm.
>I've contacted Glenn Fowler regarding this issue.
>He'll confirm what I've said.
>
>> This wouldn't be an issue for the Berkeley license, though.  I don't know
>> what the AST tools use for licensing.
>
>OK, once again:
>http://www.research.att.com/sw/license/ast-open.html

I assume you must have mentioned this before.  I missed it.

Sorry.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 08:31:49PM -0500, Christopher Faylor wrote:
>On Fri, Jan 11, 2002 at 02:03:43AM +0100, Karsten Fleischer wrote:
>>> I'm not sure but I don't think it matters if the sources are
>>> proprietary.  Maybe this is getting incredibly picky but if you adapted
>>> algorithms from other non-GPL compliant programs then that is probably
>>> an issue, too.
>>
>>I don't know if something like "If the first four bytes of a file are
>>'poop', then hold your breath" is considered an algorithm.
>>I've contacted Glenn Fowler regarding this issue.
>>He'll confirm what I've said.
>>
>>> This wouldn't be an issue for the Berkeley license, though.  I don't know
>>> what the AST tools use for licensing.
>>
>>OK, once again:
>>http://www.research.att.com/sw/license/ast-open.html
>
>I assume you must have mentioned this before.  I missed it.
>
>Sorry.

And, I'm sorry but it really looks to me like you'd need a release from
AT&T indicating that any patches you provided to us are unemcumbered by
this license.  I don't see how you can sign away the rights to any
patches that you make if you have been working on code that is covered
by this license.

Specifically, the "YOUR GRANT OF RIGHTS TO AT&T" clause seems to indicate
that they have the right to use your patches if they want them.  That is
understandable but I think that it inviolates your right to assign anything
to us.

I'll stop apologizing for this after this message but I will reiterate
that I don't like this.  I do get asked about this kind of thing all of
the time within and without Red Hat, though.  I don't want to be in a
position of having to say "Uh oh!" to our corporate counsel sometime in
the future.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Robert Collins]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
> I'll stop apologizing for this after this message but I will reiterate
> that I don't like this.  I do get asked about this kind of thing all
of
> the time within and without Red Hat, though.  I don't want to be in a
> position of having to say "Uh oh!" to our corporate counsel sometime
in
> the future.

Halp, Halp, I'm being repressed!

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Fleischer, Karsten (K.)]

> The problem is that by default the "Everyone" group has the uid and
> gid 0.  The user can change that in the passwd and group files.

OK, I'll take that out again then.

> You just should stick with uid/gid 18 for the user SYSTEM.  Are you
> familar with the NT security concept?  If you want to have a rough
> insight how that's used in Cygwin, I suggest reading
> 
>   http://cygwin.com/cygwin-ug-net/ntsec.html
> 
> It's rather old and a bit badly maintained but it's basically still
> correct.

I've read it a long time ago...

> One general question, though.  How do these changes to handle things
> like U/WIN collide with the propietary U/WIN license?  We don't want
> to have problems with AT&T suddenly.  Especially we don't want to
> have sources taken from U/WIN.

No sources were taken from UWIN or from the AST libraries.
I'm using UWIN quite a lot here at Ford, because I needed to use the MSVC++ compiler.
I've found many bugs in UWIN and I have email contact with David and Glenn on a regular basis. They asked me if I could help out porting AST to Cygwin, because they didn't want to touch (or even read) the Cygwin sources for obvious copyright problems.
The concepts I've taken from UWIN were explained to me by them verbally, so no source code involved here.
Other portions are rewritten from the AST sources (which are open source, see http://www.research.att.com/sw/license/ast-open.html).
I don't know if this license and the GPL collide, so I've rewritten the code from memory after looking at the sources.
The differences are substancial, so no problem here either.

Karsten

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 10:50:46AM -0500, Fleischer, Karsten (K.) wrote:
> >   http://cygwin.com/cygwin-ug-net/ntsec.html
> > 
> > It's rather old and a bit badly maintained but it's basically still
> > correct.
> 
> I've read it a long time ago...

I'm feeling flattered. :-)

> > One general question, though.  How do these changes to handle things
> > like U/WIN collide with the propietary U/WIN license?  We don't want
> > to have problems with AT&T suddenly.  Especially we don't want to
> > have sources taken from U/WIN.
> 
> No sources were taken from UWIN or from the AST libraries.
> I'm using UWIN quite a lot here at Ford, because I needed to use the MSVC++ compiler.
> I've found many bugs in UWIN and I have email contact with David and Glenn on a regular basis. They asked me if I could help out porting AST to Cygwin, because they didn't want to touch (or even read) the Cygwin sources for obvious copyright problems.
> The concepts I've taken from UWIN were explained to me by them verbally, so no source code involved here.
> Other portions are rewritten from the AST sources (which are open source, see http://www.research.att.com/sw/license/ast-open.html).
> I don't know if this license and the GPL collide

IANAL but AFAIK, they collide.

> , so I've rewritten the code from memory after looking at the sources.
> The differences are substancial, so no problem here either.

I think that's ok.  "Rewritten" should be enough.  IANAL, IANAL, ...

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 05:03:26PM +0100, Corinna Vinschen wrote:
>> , so I've rewritten the code from memory after looking at the sources.
>> The differences are substancial, so no problem here either.
>
>I think that's ok.  "Rewritten" should be enough.  IANAL, IANAL, ...

If you've actually looked at the UWIN sources, this is not enough.  IANAL
either, but I believe that this means you've been tainted.  That means
that we can't use your patches.  Sorry.

I hope I am misinterpreting what you said incorrectly...

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Fleischer, Karsten (K.)]

> > Glenn found some test cases where mmap() failed and has 
> also written a nice test program. I will get this to you later.
> > He also states that the value returned by getpagesize() 
> must conform to mmap() alignment by definition in the SUSv2. 
> I'm not quite sure about that, though.
> 
> See my reply to Robert.  It's just an example.  I don't have another
> reason at hand now but we already considered that change and we
> actually *had* reasons to avoid it.  Perhaps Chris can help out here.

OK.

> But, uhm, what exactly is a `superuser' from your point of view?
> We don't have that concept except for SYSTEM as _the_ user which
> is able to change user context w/o changing security policies.
> And on 9x/Me...

Does the SYSTEM user have uid == 0? Does any user have an uid == 0?
If not then it does not matter anyway. I can just leave it as it is.
If in future some superuser concept might find it's way into Cygwin, this $SHELL stuff is safe already.


Oh, I forgot to mention that I changed the rename() logic a bit.
rename("a", "b"): If "a" is really "a.exe" it is renamed to "b.exe"
rename("a", "b.suffix"): If "a" is really "a.exe" it is nevertheless renamed to "b.suffix". The ".suffix" implies that the user knows what she's doing.
rename("a.exe", "b"): The ".exe" suffix implies that the user knows what she's doing, too, so "a.exe" is renamed to "b"

This also holds for link().

I've taken that from UWIN, too.

Karsten


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 10:09:59AM -0500, Fleischer, Karsten (K.) wrote:
> > But, uhm, what exactly is a `superuser' from your point of view?
> > We don't have that concept except for SYSTEM as _the_ user which
> > is able to change user context w/o changing security policies.
> > And on 9x/Me...
> 
> Does the SYSTEM user have uid == 0? Does any user have an uid == 0?
> If not then it does not matter anyway. I can just leave it as it is.
> If in future some superuser concept might find it's way into Cygwin, this $SHELL stuff is safe already.

The problem is that by default the "Everyone" group has the uid and
gid 0.  The user can change that in the passwd and group files.
You just should stick with uid/gid 18 for the user SYSTEM.  Are you
familar with the NT security concept?  If you want to have a rough
insight how that's used in Cygwin, I suggest reading

  http://cygwin.com/cygwin-ug-net/ntsec.html

It's rather old and a bit badly maintained but it's basically still
correct.

> Oh, I forgot to mention that I changed the rename() logic a bit.
> rename("a", "b"): If "a" is really "a.exe" it is renamed to "b.exe"
> rename("a", "b.suffix"): If "a" is really "a.exe" it is nevertheless renamed to "b.suffix". The ".suffix" implies that the user knows what she's doing.
> rename("a.exe", "b"): The ".exe" suffix implies that the user knows what she's doing, too, so "a.exe" is renamed to "b"
> 
> This also holds for link().
> 
> I've taken that from UWIN, too.

Yup, that sounds reasonable to discuss.

One general question, though.  How do these changes to handle things
like U/WIN collide with the propietary U/WIN license?  We don't want
to have problems with AT&T suddenly.  Especially we don't want to
have sources taken from U/WIN.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 04:28:54PM +0100, Corinna Vinschen wrote:
> 
>   http://cygwin.com/cygwin-ug-net/ntsec.html
> 
> It's rather old and a bit badly maintained but it's basically still
> correct.

Unfortunately, it doesn't contain any word about the ability to change
user context w/o password through the seteuid() call as it's provided
by Cygwin since 1.3.x.  *sigh* I hate to work on documentation...

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Fleischer, Karsten (K.)]

> > It's a whole bunch of small fixes. I think I need to fill 
> out the assignment form.
> 
> Yeah, please send it as soon as possible since you'll have to send
> it by snail mail.  Sometimes it takes two to three weeks for some
> reason.

OK, I'll fill it out later today.

> > Is it OK to send patches to 1.3.3-2 or should I move them 
> to 1.3.6 first?
> 
> I would suggest to move them to the latest from CVS.  If you're
> always working against the latest from CVS you don't get hit too
> much by changes from other people.

I'll try that.

> > I'll give a short summary of what I've fixed:
> 
> I'll compare your below listing against current from CVS.  You should
> evaluate my answers in that light.
> 
> > - pathconf() doesn't check existance of the path
> 
> It does.  However, there's an error in _PC_PATH_MAX.   It doesn't
> validate the incoming path which could result in a SEGV.  I've
> checked in a fix.

Good.

> > - getpagesize() should return a value compatible with 
> mmap(), that is dwAllocGranularity (65536) instead of 
> dwPageSize (1024).
> 
> We discussed that months ago.  I think we're not going to change that
> (it's 4096, not 1024, btw.).

Oops, I was writing this summary from memory, I don't have the patches at hand now...

> It will result in dubious problems
> when a process mmaps a file.  For instance, the latest gcc expects to
> be able to read over the end of an mmaped file if the size is not a
> multiple of getpagesize().  Now think of a file which is 
> coincidentally
> exactly 1 page long...

Glenn found some test cases where mmap() failed and has also written a nice test program. I will get this to you later.
He also states that the value returned by getpagesize() must conform to mmap() alignment by definition in the SUSv2. I'm not quite sure about that, though.

> > - use .exe extension detection consequently in all syscalls
> 
> You mean unlink() etc.?

Yes. chmod(), link(), open(), pathconf(), rename(), truncate() and unlink() (have I missed one?) didn't check for the .exe extension.

> > - automatically add the .exe extension to a newly created 
> file on close() when the first four bytes are 0x4d, 0x5a, 
> 0x90, 0x00 (MS Executable magic bytes) and the file name 
> didn't have an extension already. (This is from UWIN, I think 
> it's really nice).
> 
> Ugh.  I'm not quite sure if I like that.

This eliminates the need to fix up programs which produce executables, e.g. ld.
Also you don't need to take care of the .exe extension in cp.
It's there automatically.

> > - exec*() functions would always invoke a /bin/sh on a file 
> that isn't a valid executable. Only execlp()/execvp() should 
> do so, others must return with an ENOEXEC.
> 
> Sounds like a bug.

Yes. A big one.

> > - the exec*() fix revealed a bug with vfork() in ash
> 
> We have some vfork() changes in the meantime and even ash had an 
> related error which should be fixed.

Maybe we fixed the same error. I'll send you the details.

> > - use the contents of $SHELL instead of /bin/sh for 
> execvp()/execlp() and system() (with some additional checks, 
> e.g. do not use a csh, use only 'trusted' shells from /bin, 
> /usr/bin, /usr/local/bin etc.). This allows the user to 
> select his favorite shell manually, so no more "copy 
> /bin/bash to /bin/sh" troubles. (This is also from UWIN).
> 
> Hmm, interesting idea...

OK, more detailed. I allow only absolute pathes in $SHELL and don't allow any *csh.
If superuser then only shells from [/usr][/local]/bin are considered trusted shells.
If not superuser shells from other directories are allowed, but if uid != euid or gid != egid the shell and the directory where it resides must not be writable.
Fall back value is /bin/sh.

> > - some mmap() problems have been fixed.
> 
> Since I have changed so much in mmap() you should actually first
> compare your changes to the current version.

I'll do that.

> > - utime() doesn't mark st_ctime for update
> 
> Really?  I would never think so when inspecting the source code.

Has this been fixed meanwhile? Also other calls like chmod() must mark st_ctime for update. My patches are not complete here.

Karsten

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 09:13:01AM -0500, Fleischer, Karsten (K.) wrote:
> > > It's a whole bunch of small fixes. I think I need to fill 
> > out the assignment form.
> > 
> > Yeah, please send it as soon as possible since you'll have to send
> > it by snail mail.  Sometimes it takes two to three weeks for some
> > reason.
> 
> OK, I'll fill it out later today.

Fine.  We can need everybody who dares to change Cygwin ;-)

> > It will result in dubious problems
> > when a process mmaps a file.  For instance, the latest gcc expects to
> > be able to read over the end of an mmaped file if the size is not a
> > multiple of getpagesize().  Now think of a file which is 
> > coincidentally
> > exactly 1 page long...
> 
> Glenn found some test cases where mmap() failed and has also written a nice test program. I will get this to you later.
> He also states that the value returned by getpagesize() must conform to mmap() alignment by definition in the SUSv2. I'm not quite sure about that, though.

See my reply to Robert.  It's just an example.  I don't have another
reason at hand now but we already considered that change and we
actually *had* reasons to avoid it.  Perhaps Chris can help out here.

> > We have some vfork() changes in the meantime and even ash had an 
> > related error which should be fixed.
> 
> Maybe we fixed the same error. I'll send you the details.

Please compare with the current CVS.  Vfork() isn't in my expertise.

> > > - use the contents of $SHELL instead of /bin/sh for 
> > execvp()/execlp() and system() (with some additional checks, 
> > e.g. do not use a csh, use only 'trusted' shells from /bin, 
> > /usr/bin, /usr/local/bin etc.). This allows the user to 
> > select his favorite shell manually, so no more "copy 
> > /bin/bash to /bin/sh" troubles. (This is also from UWIN).
> > 
> > Hmm, interesting idea...
> 
> OK, more detailed. I allow only absolute pathes in $SHELL and don't allow any *csh.
> If superuser then only shells from [/usr][/local]/bin are considered trusted shells.
> If not superuser shells from other directories are allowed, but if uid != euid or gid != egid the shell and the directory where it resides must not be writable.
> Fall back value is /bin/sh.

But, uhm, what exactly is a `superuser' from your point of view?
We don't have that concept except for SYSTEM as _the_ user which
is able to change user context w/o changing security policies.
And on 9x/Me...

> > > - utime() doesn't mark st_ctime for update
> > 
> > Really?  I would never think so when inspecting the source code.
> 
> Has this been fixed meanwhile? Also other calls like chmod() must mark st_ctime for update. My patches are not complete here.

I have searched in the ChangeLog since I'm thinking to have a vague
memory about soemthing related.  Unfortunately I couldn't find that.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 03:37:41PM +0100, Corinna Vinschen wrote:
>On Thu, Jan 10, 2002 at 09:13:01AM -0500, Fleischer, Karsten (K.) wrote:
>>Glenn found some test cases where mmap() failed and has also written a
>>nice test program.  I will get this to you later.  He also states that
>>the value returned by getpagesize() must conform to mmap() alignment by
>>definition in the SUSv2.  I'm not quite sure about that, though.
>
>See my reply to Robert.  It's just an example.  I don't have another
>reason at hand now but we already considered that change and we
>actually *had* reasons to avoid it.  Perhaps Chris can help out here.

Sorry, I don't remember the discussion.

>>>We have some vfork() changes in the meantime and even ash had an
>>>related error which should be fixed.
>>
>>Maybe we fixed the same error.  I'll send you the details.
>
>Please compare with the current CVS.  Vfork() isn't in my expertise.
>
>>>>- use the contents of $SHELL instead of /bin/sh for
>>>execvp()/execlp() and system() (with some additional checks, e.g.  do
>>>not use a csh, use only 'trusted' shells from /bin, /usr/bin,
>>>/usr/local/bin etc.).  This allows the user to select his favorite
>>>shell manually, so no more "copy /bin/bash to /bin/sh" troubles.  (This
>>>is also from UWIN).
>>>
>>>Hmm, interesting idea...
>>
>>OK, more detailed.  I allow only absolute pathes in $SHELL and don't
>>allow any *csh.  If superuser then only shells from [/usr][/local]/bin
>>are considered trusted shells.  If not superuser shells from other
>>directories are allowed, but if uid != euid or gid != egid the shell
>>and the directory where it resides must not be writable.  Fall back
>>value is /bin/sh.
>
>But, uhm, what exactly is a `superuser' from your point of view?  We
>don't have that concept except for SYSTEM as _the_ user which is able
>to change user context w/o changing security policies.  And on 9x/Me...

It sounds like all of this is pretty non-standard, AFAICT.  I can see
why you'd do something like this but I don't think there is any reason
to divert cygwin in this direction at this point in its life.  It's
a pretty major change.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Karsten Fleischer]

> >>OK, more detailed.  I allow only absolute pathes in $SHELL and don't
> >>allow any *csh.  If superuser then only shells from [/usr][/local]/bin
> >>are considered trusted shells.  If not superuser shells from other
> >>directories are allowed, but if uid != euid or gid != egid the shell
> >>and the directory where it resides must not be writable.  Fall back
> >>value is /bin/sh.
> >
> >But, uhm, what exactly is a `superuser' from your point of view?  We
> >don't have that concept except for SYSTEM as _the_ user which is able
> >to change user context w/o changing security policies.  And on 9x/Me...
>
> It sounds like all of this is pretty non-standard, AFAICT.  I can see
> why you'd do something like this but I don't think there is any reason
> to divert cygwin in this direction at this point in its life.  It's
> a pretty major change.

It's not a major change.
SUSv2 doesn't say that you have to use /bin/sh for a shell. It even says
that $SHELL can name the user's favorite shell.
I know that you always have trouble with users who copy /bin/bash to
/bin/sh, it's a monthly issue on the mailing list. My patch would solve this
in an easy way.
Regarding the security issues, as Corinna pointed out there's no "superuser"
with uid == 0, so the things I proposed above can be dropped.

Karsten


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Fri, Jan 11, 2002 at 02:04:47AM +0100, Karsten Fleischer wrote:
>It's not a major change.  SUSv2 doesn't say that you have to use
>/bin/sh for a shell.  It even says that $SHELL can name the user's
>favorite shell.

Every UNIX system that I've ever seen uses /bin/sh.  The SUSv2 says that
system uses the 'sh' utility.  it doesn't say that it uses the SHELL
environment variable if certain prerequisites are met.

>I know that you always have trouble with users who copy /bin/bash to
>/bin/sh, it's a monthly issue on the mailing list.

Actually, I don't think this is a really big issue.

>My patch would solve this in an easy way.

This is not a new idea.  It has been discussed a lot over the years.  I
think this is one of the places where UWIN and Cygwin differ in matters
of philosophy.  I know that UWIN does a lot of extra stuff like this.
It's basically a matter of where you draw the line, I think.  I don't
see any reason to add this extra processing to cygwin.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Gary R. Van Sickle]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Karsten Fleischer
>
> It's not a major change.
> SUSv2 doesn't say that you have to use /bin/sh for a shell. It even says
> that $SHELL can name the user's favorite shell.
> I know that you always have trouble with users who copy /bin/bash to
> /bin/sh, it's a monthly issue on the mailing list. My patch would solve this
> in an easy way.

Actually, I can easily see it causing much *more* trouble, because then there'd
be one more way to get things FUBAR.  Well actually more like Permutation(2) (or
whatever the notation is, God I'm getting old):

"Why is /bin/sh ash even though I set $SHELL to bash?"  "I replaced /bin/sh with
bash but I still get ash when I run a script."  Rinse, repeat.  I just don't see
how the cost:benefit works out on this one.

--
Gary R. Van Sickle
Brewer.  Patriot.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Fleischer, Karsten (K.)]

> >I know about that.
> 
> Ok.  Then that's the way to go.  Just follow the procedures in
> http://cygwin.com/contrib.html .  If your fix is big you'll 
> need to fill
> out an assignment form as that web page mentions.

It's a whole bunch of small fixes. I think I need to fill out the assignment form.
Is it OK to send patches to 1.3.3-2 or should I move them to 1.3.6 first?

> >So can we get down to discuss my fixes now?
> 
> If you want to start a discussion, then... start it.  You don't need
> permission to begin.
> 
> It would be nice if, before you start making observations or 
> suggesting
> fixes, you checked the mailing list archives to see if you 
> are covering
> old ground or not.

I think I've done that thoroughly enough.
I've done some fixes to mmap() that might be superseded by other patches now. I haven't checked this yet.

> Also be advised that we can't break backwards compatibility 
> in the DLL.

That's one of the reasons I haven't been coming up with my patches until now. I wanted to test it carefully.

> If you provide patches, small well-defined ones are the best. 
>  Long patches
> which do many different things are less likely to be 
> inspected or accepted.

They're quite small.

> And, if you are really going to be engaged in a discussion 
> you probably should
> subscribe to the cygwin mailing list.  I don't think we're 
> going to be able
> to remember to include your two email addresses in every 
> response to you.

Done.


I'll give a short summary of what I've fixed:

- pathconf() doesn't check existance of the path
- getpagesize() should return a value compatible with mmap(), that is dwAllocGranularity (65536) instead of dwPageSize (1024).
- use .exe extension detection consequently in all syscalls
- automatically add the .exe extension to a newly created file on close() when the first four bytes are 0x4d, 0x5a, 0x90, 0x00 (MS Executable magic bytes) and the file name didn't have an extension already. (This is from UWIN, I think it's really nice).
- exec*() functions would always invoke a /bin/sh on a file that isn't a valid executable. Only execlp()/execvp() should do so, others must return with an ENOEXEC.
- the exec*() fix revealed a bug with vfork() in ash
- use the contents of $SHELL instead of /bin/sh for execvp()/execlp() and system() (with some additional checks, e.g. do not use a csh, use only 'trusted' shells from /bin, /usr/bin, /usr/local/bin etc.). This allows the user to select his favorite shell manually, so no more "copy /bin/bash to /bin/sh" troubles. (This is also from UWIN).
- some mmap() problems have been fixed.
- utime() doesn't mark st_ctime for update

Does this sound OK for you, especially the UWIN things I'm mimicing?

Karsten

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 07:59:12AM -0500, Fleischer, Karsten (K.) wrote:
> It's a whole bunch of small fixes. I think I need to fill out the assignment form.

Yeah, please send it as soon as possible since you'll have to send
it by snail mail.  Sometimes it takes two to three weeks for some
reason.

> Is it OK to send patches to 1.3.3-2 or should I move them to 1.3.6 first?

I would suggest to move them to the latest from CVS.  If you're
always working against the latest from CVS you don't get hit too
much by changes from other people.

> I'll give a short summary of what I've fixed:

I'll compare your below listing against current from CVS.  You should
evaluate my answers in that light.

> - pathconf() doesn't check existance of the path

It does.  However, there's an error in _PC_PATH_MAX.   It doesn't
validate the incoming path which could result in a SEGV.  I've
checked in a fix.

> - getpagesize() should return a value compatible with mmap(), that is dwAllocGranularity (65536) instead of dwPageSize (1024).

We discussed that months ago.  I think we're not going to change that
(it's 4096, not 1024, btw.).  It will result in dubious problems
when a process mmaps a file.  For instance, the latest gcc expects to
be able to read over the end of an mmaped file if the size is not a
multiple of getpagesize().  Now think of a file which is coincidentally
exactly 1 page long...

> - use .exe extension detection consequently in all syscalls

You mean unlink() etc.?

> - automatically add the .exe extension to a newly created file on close() when the first four bytes are 0x4d, 0x5a, 0x90, 0x00 (MS Executable magic bytes) and the file name didn't have an extension already. (This is from UWIN, I think it's really nice).

Ugh.  I'm not quite sure if I like that.

> - exec*() functions would always invoke a /bin/sh on a file that isn't a valid executable. Only execlp()/execvp() should do so, others must return with an ENOEXEC.

Sounds like a bug.

> - the exec*() fix revealed a bug with vfork() in ash

We have some vfork() changes in the meantime and even ash had an 
related error which should be fixed.

> - use the contents of $SHELL instead of /bin/sh for execvp()/execlp() and system() (with some additional checks, e.g. do not use a csh, use only 'trusted' shells from /bin, /usr/bin, /usr/local/bin etc.). This allows the user to select his favorite shell manually, so no more "copy /bin/bash to /bin/sh" troubles. (This is also from UWIN).

Hmm, interesting idea...

> - some mmap() problems have been fixed.

Since I have changed so much in mmap() you should actually first
compare your changes to the current version.

> - utime() doesn't mark st_ctime for update

Really?  I would never think so when inspecting the source code.

> Does this sound OK for you, especially the UWIN things I'm mimicing?

I don't like the idea to append a .exe suffix related to the first
bytes in the file.  But we can discuss everything, of course.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Robert Collins]

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
> > - getpagesize() should return a value compatible with mmap(), that
is dwAllocGranularity (65536) instead of dwPageSize (1024).
>
> We discussed that months ago.  I think we're not going to change that
> (it's 4096, not 1024, btw.).  It will result in dubious problems
> when a process mmaps a file.  For instance, the latest gcc expects to
> be able to read over the end of an mmaped file if the size is not a
> multiple of getpagesize().  Now think of a file which is
coincidentally
> exactly 1 page long...

I'm not sure what you are implying. unless getpagesize returns 1, the
behaviour for gcc will be consistent for all larger sizes. If it's 4k,
then a file that is 4k will behave the same way as a 64K file if the
pagesize returned is 64k.

You seem to be implying that something bad happens when the file size ==
the returned page size.

What is that bad thing?

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Fri, Jan 11, 2002 at 12:54:06AM +1100, Robert Collins wrote:
> ----- Original Message -----
> From: "Corinna Vinschen" <cygwin@cygwin.com>
> > > - getpagesize() should return a value compatible with mmap(), that
> is dwAllocGranularity (65536) instead of dwPageSize (1024).
> >
> > We discussed that months ago.  I think we're not going to change that
> > (it's 4096, not 1024, btw.).  It will result in dubious problems
> > when a process mmaps a file.  For instance, the latest gcc expects to
> > be able to read over the end of an mmaped file if the size is not a
> > multiple of getpagesize().  Now think of a file which is
> coincidentally
> > exactly 1 page long...
> 
> I'm not sure what you are implying. unless getpagesize returns 1, the
> behaviour for gcc will be consistent for all larger sizes. If it's 4k,
> then a file that is 4k will behave the same way as a 64K file if the
> pagesize returned is 64k.
> 
> You seem to be implying that something bad happens when the file size ==
> the returned page size.
> 
> What is that bad thing?

mmap (MapViewOfFile resp.) alwaus map whole pages.  A page is 4096
bytes long. 

If a file is, say, 8190 bytes, then we have a two page map, size 8192.
So we have two trailing 0 bytes.  If getpagesize() returns 4096, gcc can
count that correctly, if getpagesize returns 65536, gcc assumes 57346
trailing bytes.  No problem, gcc only accesses exactly one trailing 0 byte.

If the file is 8192 bytes long, mmap maps exactly 8192 bytes, no
trailing bytes left.  If getpagesize() returns 4096, gcc knows that,
if getpagesize returns 65536, gcc assumes 57344 trailing bytes.
Now it is a problem, since the one trailing 0 byte doesn't exist.
Segmentation fault.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Robert Collins]

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>

> mmap (MapViewOfFile resp.) alwaus map whole pages.  A page is 4096
> bytes long.
>
> If a file is, say, 8190 bytes, then we have a two page map, size 8192.
> So we have two trailing 0 bytes.  If getpagesize() returns 4096, gcc
can
> count that correctly, if getpagesize returns 65536, gcc assumes 57346
> trailing bytes.  No problem, gcc only accesses exactly one trailing 0
byte.
>
> If the file is 8192 bytes long, mmap maps exactly 8192 bytes, no
> trailing bytes left.  If getpagesize() returns 4096, gcc knows that,
> if getpagesize returns 65536, gcc assumes 57344 trailing bytes.
> Now it is a problem, since the one trailing 0 byte doesn't exist.
> Segmentation fault.

Ok. Lets see if I understand:

Let m be the size reported by getpagesize.
Let f be the size of a file gcc is mmaping.

1) Gcc can't handle a remainder of m divided by f that is greater than
<some number between  2 and 57346>.

2) If the remainfer of m divided by f is 0, gcc behaves correctly.

3) If f > m, then gcc assumes that f is m bytes long?

Sounds to me like gcc is badly broken.
i.e. in your prior example:
where m = 4096
if the file is 2048 bytes long, mmap maps exactly 2048 bytes. if m is
4096, gcc assumes there is  2048 trailing bytes. Now it is a problem,
since the one trailing 0 byte doesn't exist. Segmentation fault.

IOW, I don't see how the 4K vs 64K thing affects this scenario, it seems
to be driven purely by the fact the m != 1.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Corinna Vinschen]

On Fri, Jan 11, 2002 at 09:32:57PM +1100, Robert Collins wrote:
> ----- Original Message -----
> From: "Corinna Vinschen" <cygwin@cygwin.com>
> 
> > mmap (MapViewOfFile resp.) alwaus map whole pages.  A page is 4096
> > bytes long.
> >
> > If a file is, say, 8190 bytes, then we have a two page map, size 8192.
> > So we have two trailing 0 bytes.  If getpagesize() returns 4096, gcc
> can
> > count that correctly, if getpagesize returns 65536, gcc assumes 57346
> > trailing bytes.  No problem, gcc only accesses exactly one trailing 0
> byte.
> >
> > If the file is 8192 bytes long, mmap maps exactly 8192 bytes, no
> > trailing bytes left.  If getpagesize() returns 4096, gcc knows that,
> > if getpagesize returns 65536, gcc assumes 57344 trailing bytes.
> > Now it is a problem, since the one trailing 0 byte doesn't exist.
> > Segmentation fault.
> 
> Ok. Lets see if I understand:
> 
> Let m be the size reported by getpagesize.
> Let f be the size of a file gcc is mmaping.
> 
> 1) Gcc can't handle a remainder of m divided by f that is greater than
> <some number between  2 and 57346>.
> 
> 2) If the remainfer of m divided by f is 0, gcc behaves correctly.
> 
> 3) If f > m, then gcc assumes that f is m bytes long?
> 
> Sounds to me like gcc is badly broken.
> i.e. in your prior example:
> where m = 4096
> if the file is 2048 bytes long, mmap maps exactly 2048 bytes.

No, it maps 4096 bytes since memory maps always use chunks of
the pagesize which is 4096 on Win32.

if m is
> 4096, gcc assumes there is  2048 trailing bytes. Now it is a problem,
> since the one trailing 0 byte doesn't exist. Segmentation fault.
> 
> IOW, I don't see how the 4K vs 64K thing affects this scenario, it seems
> to be driven purely by the fact the m != 1.

Sorry but you didn't understand or I don't understand your
above reasoning which is likely.

GCC isn't broken (from the gcc's engineers point of view) but it's
using a property of mmap: mmap always maps whole pages and the
trailing unused bytes in a mmap'd page are always zeroed out.

This fact is used for some sort of speed up when reading header
files.  IMO that's ugly but...
Anyway, gcc reads a C header file just as a string with trailing 0.

For that reason gcc has to know the pagesize of the system, returned
by getpagesize().

If the file size is not exactly a multiple of the pagesize, you
always have a trailing zero so gcc can use the above method.  If
a file has no trailing 0 byte (which would happen very seldom)
gcc would have to fallback to another method (I do know nothing
about).

Now, the pagesize on Windows is 4K.  If the file size is coincidentally
4096 or 8192 or any other multiple of 4K, gcc knows that it has to
fallback to it's "slow" method since getpagesize() has returned the
correct value.  If we change getpagesize() to return the granularity
(64K) instead of the pagesize, gcc would wrongly assume that the
file doesn't exactly match the pagesize so it would assume that
it can use the "fast" method and would expect a trailing 0 byte.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Robert Collins]

===
----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>

> Now, the pagesize on Windows is 4K.  If the file size is
coincidentally
> 4096 or 8192 or any other multiple of 4K, gcc knows that it has to
> fallback to it's "slow" method since getpagesize() has returned the
> correct value.  If we change getpagesize() to return the granularity
> (64K) instead of the pagesize, gcc would wrongly assume that the
> file doesn't exactly match the pagesize so it would assume that
> it can use the "fast" method and would expect a trailing 0 byte.

Now I get it! Thanks.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 02:45:51PM +0100, Corinna Vinschen wrote:
>> Is it OK to send patches to 1.3.3-2 or should I move them to 1.3.6 first?
>
>I would suggest to move them to the latest from CVS.  If you're
>always working against the latest from CVS you don't get hit too
>much by changes from other people.

Yes.  This is a requirement.  Latest CVS.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

ksh on Cygwin

[Karsten Fleischer]

Hi Cygwin folks,

having seen some references to pdksh on the list today I think I must have a
"coming out" now.
I've been working with David Korn and Glenn Fowler some weeks ago to get the
real ksh93 and all the other AT&T stuff (AST libraries and tools) going on
Cygwin.
There are still some problems here and there, but it works quite well now.
We have found some SUSv2 incompatibilities and some inconsistencies within
the Cygwin DLL.
I've fixed most of them, but unfortunately my fixes are against the 1.3.3
DLL, and you folks are quite ahead of me now.
Also, some of my fixes mimic UWIN behavior...
Cygwin developers, if you're interested, please feel free to contact me.
Please mail to me at both of these addresses then so that I can reply on
time:
K.Fleischer@omnium.de
kfleisc1@getrag-ford.com

Karsten


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 01:50:46AM +0100, Karsten Fleischer wrote:
>Hi Cygwin folks,
>
>having seen some references to pdksh on the list today I think I must have a
>"coming out" now.
>I've been working with David Korn and Glenn Fowler some weeks ago to get the
>real ksh93 and all the other AT&T stuff (AST libraries and tools) going on
>Cygwin.
>There are still some problems here and there, but it works quite well now.
>We have found some SUSv2 incompatibilities and some inconsistencies within
>the Cygwin DLL.
>I've fixed most of them, but unfortunately my fixes are against the 1.3.3
>DLL, and you folks are quite ahead of me now.
>Also, some of my fixes mimic UWIN behavior...
>Cygwin developers, if you're interested, please feel free to contact me.

Sorry.  That's not how it works.

If you have patches to provide, check out the cygwin web page.  Click on
the "Contributing" link.

If you really are thinking about providing a modified version of the cygwin
DLL with ksh, then I hope you think again.  It's a very bad idea.

However, if you insist, I hope that you'll have a separate mailing list
available for support.  We definitely won't be supporting it here.

>Please mail to me at both of these addresses then so that I can reply on
>time:
>K.Fleischer@omnium.de
>kfleisc1@getrag-ford.com

Hmm.  How odd.

I assume that I have to spell this out:  Please reply to the mailing list.
That's how most free software projects get patches into the code base.

If you have questions, want to report bugs, or submit patches, the cygwin
mailing list is the place to do this.  It's sort of a shame that you weren't
doing that all along, in fact.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: ksh on cygwin

[Karsten Fleischer]

> Sorry.  That's not how it works.
>
> If you have patches to provide, check out the cygwin web page.  Click on
> the "Contributing" link.

I know about that.

> If you really are thinking about providing a modified version of
> the cygwin
> DLL with ksh, then I hope you think again.  It's a very bad idea.

Sorry, that was not my intention. Never.
I've put a lot of work into my fixes, but Cygwin development went off too
fast for me to keep up pace.
There's already a great interest in having ksh on Cygwin at Bell Labs. I'm
interested to get my patches into the official Cygwin release.

> However, if you insist, I hope that you'll have a separate mailing list
> available for support.  We definitely won't be supporting it here.

???

> >Please mail to me at both of these addresses then so that I can reply on
> >time:
> >K.Fleischer@omnium.de
> >kfleisc1@getrag-ford.com
>
> Hmm.  How odd.

Not so odd. I'm not monitoring the mailing list all the time and I don't
have access to the other mail account at the two places.

> I assume that I have to spell this out:  Please reply to the mailing list.
> That's how most free software projects get patches into the code base.

I know. I'm not that dumb.

> If you have questions, want to report bugs, or submit patches, the cygwin
> mailing list is the place to do this.  It's sort of a shame that
> you weren't
> doing that all along, in fact.

It was quite a bunch of things I had to discuss. Along them were copyright
infringements. As you might know, David Korn and Glenn Fowler are working
for AT&T.
I am a freelancer, so there are no copyright problems. So we decided that
they should work out the bug reports (some of which turned out to be bugs in
their software), and I do the fixes.
It was meant to prove that AST/ksh works on Cygwin, or, the other way round,
Cygwin is capable to run AST/ksh. It does. q.e.d.

So can we get down to discuss my fixes now?

Karsten


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 02:25:53AM +0100, Karsten Fleischer wrote:
>> Sorry.  That's not how it works.
>>
>> If you have patches to provide, check out the cygwin web page.  Click on
>> the "Contributing" link.
>
>I know about that.

Ok.  Then that's the way to go.  Just follow the procedures in
http://cygwin.com/contrib.html .  If your fix is big you'll need to fill
out an assignment form as that web page mentions.

>So can we get down to discuss my fixes now?

If you want to start a discussion, then... start it.  You don't need
permission to begin.

It would be nice if, before you start making observations or suggesting
fixes, you checked the mailing list archives to see if you are covering
old ground or not.

Also be advised that we can't break backwards compatibility in the DLL.

If you provide patches, small well-defined ones are the best.  Long patches
which do many different things are less likely to be inspected or accepted.

And, if you are really going to be engaged in a discussion you probably should
subscribe to the cygwin mailing list.  I don't think we're going to be able
to remember to include your two email addresses in every response to you.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/