Mail Archives: cygwin-apps/2002/03/28/17:14:34

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
Date: Thu, 28 Mar 2002 17:14:39 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: How to create a ksh93 package...
Message-ID: <>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <200203281622 DOT g2SGMrO28807 AT dymwsm11 DOT mailwatch DOT com>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/

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?

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'd suggest a simple ksh release without the plugins (or whatever
they're called) and a separate package for the plugins.  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.

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

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