This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to create a ksh93 package...


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]