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
Message-ID: <3CA3A839.5040307@ece.gatech.edu>
Date: Thu, 28 Mar 2002 18:33:13 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: How to create a ksh93 package...
References: <200203281622 DOT g2SGMrO28807 AT dymwsm11 DOT mailwatch DOT com> <20020328221439 DOT GJ16757 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

First, read my other message (sent immediately prior to this one)

Christopher Faylor wrote:

> On Thu, Mar 28, 2002 at 11:21:22AM -0500, Fleischer, Karsten (K.) wrote:
> 
>>Would other executables that are not stub executables but alternative
>>version to existing commands go there, too?  AT&T have own versions of
>>dd, df, du, ed, expand, file, find, grep, od, pr, sed, sort, strings,
>>etc.  The other tools that have no Cygwin pendant, like cql, ditto,
>>iffe, look, mamake, nmake, ratz, etc., they would go into /usr/bin?


Nope -- if included at all, they should be segregated into 
/usr/libexec/ast/bin/* or wherever.  We might eventually have our own 
'look' package that wouldn't depend on cygksh*.dll -- and would 
therefore be preferable to non-ksh users (What? you mean I have to 
install the whole ast package just to get look?)


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


I doubt they are required. (ksh "the mega package" sounds a lot like 
cygwin's old "full.exe"...).  If ksh "the mega package" was split into 
about four components (or more), I think it would be manageable.  I'd 
install the base ksh package and probably the -accel package, but not 
the other stuff...

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


Yep.  'ksh' and 'ksh-accel' in my other message.

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


If they are segregated into a separate directory that is not normally in 
the path, then only hardcore ksh'ers will set their path to get them, 
and those guys "just want my ksh dammit".  ksh-newbies like me -- I'll 
use my GNU tools thank you and keep /usr/libexec/ast/bin OUT of my path.

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


As far as I understand, you have to explicitly enable each and every 
plugin.  So only those that go thru the affirmative step of enabling 
them will ever run in to variant behavior -- if there is any.  That's 
okay.  It's all about freedom.

I understand "I just want my ksh" -- think "I just want my GNU tools on 
windows". == cygwin.


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


Yep.

--Chuck