Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: cygwin-apps AT cygwin DOT com Subject: Re: How to create a ksh93 package... Message-ID: <20020328221439.GJ16757@redhat.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203281622.g2SGMrO28807@dymwsm11.mailwatch.com> User-Agent: Mutt/1.3.23.1i 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