Mail Archives: cygwin-apps/2002/03/28/18:35:09

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <>
Date: Thu, 28 Mar 2002 18:25:44 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Fleischer, Karsten (K.)" <kfleisc1 AT getrag-ford DOT com>
CC: "'cygwin-apps AT cygwin DOT com'" <cygwin-apps AT cygwin DOT com>
Subject: Re: How to create a ksh93 package...
References: <200203281622 DOT g2SGMrO28807 AT dymwsm11 DOT mailwatch DOT com>

Fleischer, Karsten (K.) wrote:

> I'd prefer the name /usr/libexec/ast then.
> 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?
> 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! :-)

> in the full ast-open package /bin directory, and I have to distribute them into two different directories?
> No thanks.
> Chances that I would overwrite something existing by error are high.

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 

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...)

>> > The ksh93 package would make a symlink /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.
>>This is a bad idea.  You can't use symlinks for DLLs, and 
>>DLLs must be 
>>in the path 
> I know.

Also, symlinks mean that the shell cannot be started by windows; windows 
must then use the full (deep) path.

>>-- so you need to put /usr/ast/bin (or 
>>/usr/bin/ksh/bin or 
>>/usr/libexec/ksh/ in the PATH somewhere.  But it needs to be 
>>at the END 
>>of the path for "normal" cygwin, and at the beginning of the path for 
>>"ksh-centric" usage.  
>>Blech.  (okay, if .dll is in same dir as .exe, 
>>it'll work...but geez)
> 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...

>>Why not let ksh be a full-fledged cygwin package?

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:


/etc/postinstall/  <<< 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 ...


/usr/libexec/ast/bin/*.dll (but not the ones in the basic ksh pkg)
/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 ...

next, there's the full-blown ast package, which contains all those other 
  (GNU replacement) executables and such.


/usr/libexec/ast/man/?  <<< more stuff
   requires: ksh-accel ksh ...

and finally, there's the devel package, which contains the include files 
and import/static libs:


   requires: ksh-ast ksh-accel ksh ...

> 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...


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019