Mail Archives: cygwin-apps/2002/03/28/11:24:07

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: <>
From: "Fleischer, Karsten (K.)" <kfleisc1 AT getrag-ford DOT com>
To: "'Charles Wilson'" <cwilson AT ece DOT gatech DOT edu>,
"'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 11:21:22 -0500
MIME-Version: 1.0
X-MAILWATCH-INSTANCEID: 0102000a528130ec-5b89-4928-8698-a2473e896c48
X-OriginalArrivalTime: 28 Mar 2002 16:22:54.0595 (UTC) FILETIME=[D0840D30:01C1D674]

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

OK, I see.

> BTW, I thought you weren't installing the man pages?

Man pages will not be in my ksh93 package. AT&T have man pages in their ast-ksh package.
For people who want to fully fledged ast-open package, man pages will be useful. That would be another package, though.

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

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

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

I know.

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

> Why not let ksh be a full-fledged cygwin package?
> /usr/bin/ksh.exe
> /usr/bin/*.dll
> /usr/libexec/ksh/*.exe
> /usr/lib/*
> (what is "fun"?)

A directory for auto-load shell functions.

> and you already said you weren't installing the man pages...

See above.

>  > 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...).
> /usr/include/*
> /usr/lib/*

We might have conflicts here with headers, too. I have to check.

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