Mail Archives: cygwin-apps/2002/03/28/10:44:03

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 10:46:14 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; 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: <200203281431 DOT g2SEVrO11438 AT dymwsm11 DOT mailwatch DOT com>

Fleischer, Karsten (K.) wrot

 > 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

Bad.  With one exception, we've decided not to clutter the top level 
/usr directory with a bunch of package-specific subdirs.  (The exception 
is the 'autotool' tree, which acts as a home for automake-devel, 
automake-stable, autoconf-devel, autoconf-stable, libtool-devel, and 
libtool-stable.  And there was a lot of argument about it.)  BTW, I 
thought you weren't installing the man pages?

Maybe we need a top-level /opt directory?  OTOH, I see no need for 
/usr/ast/* instead of "ksh, and the DLLs go in /usr/bin; stub 
executables that are ksh-replacements for "standard unix tools" -- 
regardless of whether cygwin has "normal" ports yet -- go in 
/usr/bin/ksh/ or /usr/libexec/ksh/ or wherever.

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

This is a bad idea.  You can't use symlinks for DLLs, and DLLs must be 
in the 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)

Why not let ksh be a full-fledged cygwin package?
(what is "fun"?)
and you already said you weren't installing the man pages...

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

Use dummy -src packages, for now.  See ncurses/libncurses, 
gettext/libintl1, etc.


- Raw text -

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