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
Reply-To: <K DOT Fleischer AT omnium DOT de>
From: "Karsten Fleischer" <Karsten DOT Fleischer AT gmx DOT de>
To: <cygwin-apps AT cygwin DOT com>
Subject: FW: How to create a ksh93 package...
Date: Fri, 29 Mar 2002 18:02:36 +0100
Organization: Omnium Software Engineering
Message-ID: <00e901c1d743$86fea2e0$f20114d5@muffin>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal

Oops, forgot to reply to the list...

> -----Original Message-----
> From: Karsten Fleischer [mailto:Karsten DOT Fleischer AT gmx DOT de] 
> Sent: Freitag, 29. Marz 2002 17:55
> To: 'Charles Wilson'
> Subject: RE: How to create a ksh93 package...
> 
> 
> > > There are > 150 DLLs, executables and scripts altogether
> > 
> > 
> > !!!!!
> > 
> > I thought we were talking about a shell, here, not a total
> > and complete 
> > rewrite of the entire GNU/BSD/Linux environment! :-)
> 
> OK, some words on ast:
> 
> Reusability is a core concept of UNIX systems. You can create 
> your own "meta tools" from the standard tools by using pipes 
> and writing scripts, reusing the tools as you like. The shell 
> is the "glue" and thus takes a special position. 
> Unfortunately, the concept of reusability on the source code 
> level is not common practice. Take these two commands, issued 
> from a shell: $ find . -name "*foo*" $ chmod -R *foo* What do 
> they have in common? Both are doing a directory traversal and 
> in both cases pattern matching is involved. In the first 
> case, find has to do the pattern matching itself, in the 
> second case the shell will perform pattern matching before 
> executing the command. Chances are good that the find and 
> chmod commands have different implementations of the 
> directory traversal, the same for find's and the shell's 
> pattern matching. AT&T have isolated such common operations 
> like directory traversal and pattern matching (and lots of 
> others) into the ast core library (ast54.dll), tweaked the 
> algorithms for high perfomance, and rewritten the common UNIX 
> tools to use this library. The executables are smaller and 
> faster than on most common UNIX implementations. They are 
> working on ast since 1985 and in the meantime tons of tools 
> have accumulated. As said above the shell has a special role 
> in the UNIX environment and thus the ksh shell can easily be 
> taken out of the ast package and be distributed seperately.
> 
> > Yeah, in that case most DLL's and EXE's should go in
> > /usr/libexec/ast/* 
> > or /usr/libexec/ast/bin/* or whatever.
> > 
> > *EXCEPT* for the specific DLLs that are necessary for proper
> > -- but not 
> > accelerated -- operation of the ksh.exe itself.  Those DLLs, and 
> > ksh.exe, should go into /usr/bin.  (C'mon, it's not that 
> hard, after 
> > 'make install' to 'mv $MY_SHORT_LIST $inst/usr/bin' within 
> your build 
> > script...
> 
> OK, you've won :-)
> 
> > BTW, are you following the proper naming scheme for DLLs on cygwin?
> > cygfoo-N.dll (or cygfooN.dll), import lib libfoo.dll.a, static lib 
> > libfoo.a?  (Never mind, 'cygcmd12.dll' -- looks like you are...)
> 
> Ha, you got me.
> I have been talking with Glenn Fowler about DLL naming 
> schemes for Cygwin, but obviously the import lib naming 
> scheme has slipped the discussion. It is currently foo.lib. 
> I'll change that and inform Glenn. Thanks for the hint.
> 
> > Also, symlinks mean that the shell cannot be started by
> > windows; windows 
> > must then use the full (deep) path.
> 
> Windows, yeah, windows... Almost forgot.
> 
> > > That's why I wanted to put all the ast .exe files into a
> > seperate */bin dir along with the DLLs.
> > 
> > I understand the reasoning.  But relying on the runtime loader's
> > "samedir" behavior seems like a bad idea to me...but perhaps not...
> 
> In this case I like the behavior, in most other cases not 
> (cd'ing into a dir with a stone old cygwin1.dll and then 
> wondering what has happened...)
> 
> > Okay, how about this, then:
> > 
> > the minimal runtime package; contains just ksh.exe, the ABSOLUTELY
> > necessary DLLs (cygast54.dll, cygcmd12.dll, cygdll10.dll, 
> > cygshell11.dll?), ksh.1, and basic documentation:
> > 
> > ksh-VER-REL:
> > 
> > /usr/bin/ksh.exe
> > /usr/bin/cyg???.dll
> > /usr/man/man1/ksh.1
> 
> The man pages for ksh and standard builtins are integrated 
> into ksh. You can view them with the "--man" options, e.g. 
> ksh --man, cd --man. The man pages I will be omitting from 
> the AT&T ast-ksh package are related to the ast54.dll and not 
> very useful for normal users.
> 
> > /usr/doc/ksh/....
> > /usr/doc/Cygwin/ksh-x.y.z.README
> 
> Yeah, I must be writing something.
> 
> > /usr/info/ksh.info?
> 
> Don't have that.
> 
> > /etc/postinstall/ksh.sh  <<< runs install-info...
> 
> > then, there's the "acceleration pack" which contains only the
> > loadable 
> > functions (and the dlls on which they may subsequently depend), etc.
> >    requires: cygwin ...
> 
> Don't confuse loadable utilites ("builtins") and loadable 
> functions. A loadable function is a normal shell function, 
> like: function foo {
> 	print foo
> }
> If you put this function in a file with the same name as the 
> function ("foo") into a directory which is in the FPATH 
> variable, ksh will automatically find and load this function. 
> Very useful to make shell functions available to all users 
> without having to change the .profile.
> 
> I assume you are talking about the "builtins".
> Currently, ksh is already linked with the cygcmd12.dll, so 
> the loadable utilities are already there. But not the 
> standalone versions. I'm almost sure this can be changed so 
> that ksh loads the cygcmd12.dll on demand. I'll have to ask 
> Glenn, there are myriads of options how to build ast.
> 
> > ksh-accel-VER-REL:
> > 
> > /usr/libexec/ast/bin/*.dll (but not the ones in the basic ksh pkg)
> > /usr/libexec/ast/fun/*
> > /usr/libexec/ast/man/?
> 
> Man pages for the tools are also integrated into the tools.
> 
> > /usr/libexec/ast/info/?
> > /usr/doc/kst-accel/*  << maybe just a pointer into /usr/doc/ksh/ 
> > /usr/doc/Cygwin/ksh-accel-x.y.z.README  << "go look here..."
> >    requires: ksh ...
> 
> That's OK.
> 
> > next, there's the full-blown ast package, which contains all
> > those other 
> >   (GNU replacement) executables and such.
> 
> > and finally, there's the devel package, which contains the
> > include files 
> > and import/static libs:
> 
> Sounds like this is the way to go.
> 
> > > We might have conflicts here with headers, too. I have to check.
> > 
> > Since it looks like ksh implements a whole 'nother set of
> > implementations of common functions (in its various 
> > libraries) -- yeah, 
> > that seems pretty likely to clobber some existing or future stuff. 
> > Better segregate these under /usr/libexec/ast too...
> 
> Yes.
> 
> Karsten
>