astksh review

[Igor Pechtchanski]

On Fri, 23 May 2003, Nicholas Wourms wrote:

> alcocer@helixdigital.com wrote:
> > On Mon, May 19, 2003 at 09:09:46AM +0100, Elfyn McBratney wrote:
> >
> >>I created the ksh symlink so users wouldn't have to edit their shebang
> >>lines to point to `/bin/pdksh' but now we have the proper ksh (available)
> >>I suppose I could get rid of it. What's the feeling?
> >>
> >>We could do one of
> >>
> >>  1. Remove the ksh symlink from the pdksh package.
> >>  2. Rename ksh.exe (in astksh) to astksh.exe and have a ksh symlink to
> >>     astksh.exe
> >>  3. Maybe only two options. :-)
> >>
> >>these?
> >
> >
> > How about:
> >     4. Deprecate the pdksh package.
> >
> > Now that we have the real, honest-to-goodness ksh, do we really need
> > pdksh? Just a suggestion...
> >
>
> I totally agree, there is no reason why pdksh should be the default ksh.
>   Let users make the symlink themselves.  We should always allow "The
> Real Thing" to trump some knockoff...
>
> [Still trying to dig out from under a backlog...]

If the user has installed pdksh before, and now wants ksh93 to be his
default ksh, he can remove the symlink himself before installing astksh
(this might merit a mention in the release notes).

However, this brings a valid point: suppose a user wants to switch, and
uninstalls the pdksh package.  The symlink will still be there (although
it will be broken).  So, when the user installs astksh, he will have a
broken /bin/ksh symlink pointing to a nonexistent pdksh.exe.
Perhaps the postinstall script should be smarter, and check not only that
the link exists, but also that it's valid, and if it isn't, replace it.
This goes for pdksh's postinstall script as well (and others that do this
kind of thing).

This also relates to an issue that I wanted to raise earlier: when doing a
search for files at <http://cygwin.com/packages/>, those files that are
created by postinstall scripts (e.g., symlinks) will not show up in the
listing.
So, it might be a good idea to keep a manifest of files that would be
potentially created by postinstall scripts, and to remove those files when
the package is removed.  It's possible that setup will have a separate
mechanism for tracking this.  Frankly, I don't have a concrete suggestion
on how to implement this, but thought I'd at least get this into the
archives and make people aware of the issues.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton