Mail Archives: cygwin-apps/2002/03/29/12:11:01
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
>
- Raw text -