Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
X-pair-Authenticated: 213.20.1.227
From: "Karsten Fleischer" <K DOT Fleischer AT omnium DOT de>
To: <cygwin-apps AT cygwin DOT com>
Subject: RE: How to create a ksh93 package...
Date: Fri, 29 Mar 2002 16:56:16 +0100
Organization: Omnium Software Engineering
Message-ID: <00e001c1d73a$43392ca0$f20114d5@muffin>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
In-reply-to: <20020328221439.GJ16757@redhat.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal

> I'm not interested in AT&T's implementations of other 
> utilities, actually.  Why would we include those?  If they 
> are a requirement for ksh then I'm not sure I want ksh.

And I'm not interested in using the GNU tools anymore on Cygwin, since I
have the AT&T tools now.
I'm using them on SunOS, HP-UX, U/Win and now on Cygwin, too.
I don't know how many people out there would be using them, though.
Of course they are _not_ a requirement for ksh.
I wonder what made you think that?
I was always talking about separate packages, ksh (with support DLLs)
being one of them.
You could also use the AT&T tools with bash if you wanted to.


> I'd suggest a simple ksh release without the plugins (or 
> whatever they're called) and a separate package for the 
> plugins.  

That was exactly my idea.

> If you have other executables that are not plugins 
> then I think they will just be confusing and I really don't 
> think I'm interested.

Maybe you aren't interested. Others might be. Where's the problem?
The ast tools would live in a separate directory. If you want to use
them, change your PATH.

> Actually, if the plugins work differently from the 
> stand-alone versions then I have reservations, too.

I quote Glenn Fowler:
"the standalone commands are also linked against libcmd, so the builtin
and standalone versions have exactly the same implementation no code in
libcmd uses the ksh API".
The plugin versions are activated with the "builtin" command.
One should be aware that now the ast version is active and it won't
understand any GNU specific options.
However, if you stick to using options specified in the SUS, you won't
have any problems.
The package with the standalone versions is there for people who want to
be sure that they are always using the same implementation.

> It sure sounds like this should be one (or many) different 
> packages, though, regardless.

Yes.

Karsten