RE: astksh review

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Sat, 24 May 2003, Karsten Fleischer wrote:

> > > > 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).
>
> This is the postinstall script I'm going to put in the astksh package:
>
>                 if [ ! -e /bin/ksh.exe ]; then
>                     ln -s ksh93.exe /bin/ksh.exe
>                 else
>                     echo "/bin/ksh.exe already exists"
>                 fi
>                 if [ ! -e /usr/man/man1/ksh.1 ]; then
>                     ln -s ksh93.1 /usr/man/man1/ksh.1
>                 else
>                     echo "/usr/man/man1/ksh.1 already exists"
>                 fi
>                 if [ -f /etc/shells ]; then
>                     for i in /bin/ksh93 /bin/ksh /usr/bin/ksh93 /usr/bin/ksh
>                     do
>                         if ! grep $i /etc/shells >/dev/null 2>&1; then
>                           echo $i >> /etc/shells
>                             echo "$i added to /etc/shells"
>                         else
>                             echo "$i already in /etc/shells"
>                         fi
>                     done
>                 else
>                     echo "no /etc/shells file"
>                 fi
>                 exit 0
>
> I have no idea if this is cygwinly correct, I took the pdksh postinstall
> for an example.

Looks ok, except that you should probably also check for the existence of
/bin/ksh as a symbolic link...  Same goes for the pdksh postinstall
script.

> > 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.
>
> You mean something like this:
>
>                 if [ -L /bin/ksh.exe -a ! /bin/ksh.exe -ef /bin/pdksh.exe ]; then
>                         rm -f /bin/ksh.exe
>                         ln -s ksh93.exe /bin/ksh.exe
>                 fi
>
> Ugly, because the pdksh and ksh93 and eventually Peter Brutzelmann's
> KornShell clone maintainers have to communicate.

Not at all.  I meant simply checking that the link points to a valid
executable (whatever it is).  Something like

	if [ -L /bin/ksh.exe -a -e `readlink -n /bin/ksh.exe` ]; then
		ln -fs ksh93.exe /bin/ksh.exe
	fi

(the above depends on readlink).

FYI, as shown above, you can use "ln -fs" instead of removing the file.
Also, the test you used wouldn't work, since you're checking that the
symbolic link and the executable have the same inode, and they never will.

> OK, I can live with this as long as we don't have any other ksh.exe
> candidates besides pdksh and ksh93 :)
> I already put some pdksh info into the astksh README.

That's always good to have.  I suspect you'll want to update the README
again when another ksh variant shows up...

> BTW, the above won't work anyway with the .exe suffix, you'll run into
> one of cygwin's bogosities:
> (Suppose you got vim installed, /bin/vi is a symbolic link to /bin/vim)
>
> $ if [ /bin/vi.exe -ef /bin/vim.exe ]; then echo yo; fi
> $ if [ /bin/vi -ef /bin/vim ]; then echo yo; fi
> yo
>
> I'll leave this as an exercise to the cygwin kernel hackers. I must not
> do cygwin kernel hacking anymore, since I had a chance to glimpse at the
> uwin code and thus am tainted.

The above has been discussed, and is unlikely to be changed.  I think
you're better off giving the symbolic link a name without the .exe suffix,
so symlinks stay symlinks, and executables stay executables.  One drawback
of the symlink approach is that these commands cannot be run from cmd.exe
at all.
	Igor

> Karsten
>
> P.S.: The package update might take some more time, some bugs showed up.
> I guess I can update next Thursday.

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