Mail Archives: cygwin-apps/2002/03/28/18:42:40

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: <>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <>
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>

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.



- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019