Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Message-Id: <200203281431.g2SEVrO11438@dymwsm11.mailwatch.com>
From: "Fleischer, Karsten (K.)" <kfleisc1 AT getrag-ford DOT com>
To: "'cygwin-apps AT cygwin DOT com'" <cygwin-apps AT cygwin DOT com>
Subject: Re: How to create a ksh93 package...
Date: Thu, 28 Mar 2002 09:30:17 -0500
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
HOP-COUNT: 1

Sorry for breaking the thread indexing, but I haven't been subscribed to cygwin-apps, until now and somehow I couldn't get the messages via cygwin-apps-get DOT xxx_yyy AT cygwin DOT com. So I doing a copy-and-paste from my web browser.

> >> part shall change with minor updates, so I think "ksh93m+-1" would
> >>  be the correct name for a standalone Cygwin ksh93 package. Is
> >> this OK with you?
> >>
> >
> > I think so but I'll let the collective wisdom of cygwin-apps decide.
>
> Sounds okay to me.

Good.

> > Do we really need to install other UNIX-like utilities?   That will be
> >  very confusing for users, I think.  Can't ksh just use the existing 
> utilties?
>
> Remember ksh has that in-process execution thing, where certain commands
> are replaced by internally loadable modules...the stuff Robert was
> talking about two weeks ago.
> 
> I suggest that the ksh-specific binaries should just go into
> /usr/bin/ksh/, and folks who want to get the speedup of using ksh's
> inprocess execution should just insure that /usr/bin/ksh/ is in the
> front of their path.
>
> Naturally, ksh can use the existing utilities, but you'll suffer a slowdown.
>
> Did I get that right, Karsten?

Absolutely.
This holds for the following utilities:

	basename cmp      dirname  head     mkdir    rev      tee
	cat      comm     expr     id       mkfifo   rm       tty
	chgrp    cp       fmt      join     mv       rmdir    uname
	chmod    cut      fold     ln       paste    stty     uniq
	chown    date     getconf  logname  pathchk  tail     wc

The versions that can be used as builtins are in the cygcmd12.dll
However, if you use these as builtins with ksh one might want to use the standalone versions from other shells, too.
The standalone versions are merely stubs that call the cygcmd12.dll.

The ast-open package contains many more utilities that might conflict with GNU utilities (find, for example) and other useful stuff (e.g. cql, nmake, iffe).

I'd prefer a seperate dir not hidden too deep in the tree, where all the ast utilities (including ksh) get installed, e.g.
/usr/ast/
         bin
         fun
         lib
         man

The ksh93 package would make a symlink /bin/ksh --> /usr/ast/bin/ksh so that ksh is available for everyone without changing the PATH.
The accompanying DLLs cygast54.dll, cygcmd12.dll, cygdll10.dll and cygshell11.dll reside in /usr/ast/bin, too.
Anyone who wants to use ksh with the standalone version of the cygcmd12.dll commands would have to download another package and add /usr/ast/bin to the PATH.
The remaining tools would go into yet another package.
(And we might want to have a developer package with import libs, headers etc. but that's a different thing to be discussed later...).


Regarding the sources,
I will build only with the full ast-open package which is about 8MB compressed tar.
I cannot split up the sources into seperate archives that would reflect the actual structure of the binary packages.
The source archive may be distributed, this is not the problem.
The problem is that I have a n:1 relationship between binary and source packages.
How should I deal with this?

Karsten