This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
RE: astksh review
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: cygwin-apps at cygwin dot com
- Cc: Karsten Fleischer <K dot Fleischer at omnium dot de>
- Date: Sat, 24 May 2003 00:19:47 -0400 (EDT)
- Subject: RE: astksh review
- Reply-to: cygwin-apps at cygwin dot com
On Sat, 24 May 2003, Igor Pechtchanski wrote:
> 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
^
s/-e/! -e/
> 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