This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: How to create a ksh93 package...
- From: Christopher Faylor <cgf at redhat dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 28 Mar 2002 17:14:39 -0500
- Subject: Re: How to create a ksh93 package...
- References: <200203281622.g2SGMrO28807@dymwsm11.mailwatch.com>
- Reply-to: cygwin-apps at cygwin dot com
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.
cgf