This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Upload: bash-3.0-4 [test]
- From: ericblake at comcast dot net (Eric Blake)
- To: cygwin-apps at cygwin dot com
- Date: Tue, 05 Jul 2005 16:52:19 +0000
- Subject: Re: Upload: bash-3.0-4 [test]
> On Tue, 5 Jul 2005, Eric Blake wrote:
> > #!/bin/bash
> > # If /bin/sh is missing, ash, or bash, upgrade it to the current bash.
> > case `/bin/sh.exe --version 2>&1
>
> FYI, this is missing a closing backtick and the "in".
Yep, you caught me typing on the fly instead of pasting a tested script.
Should man/man1/sh.1 always belong to bash, or should I use readlink
to ensure that I am only upgrading that link if it was to ash? In other
words, for users smart enough to replace /bin/sh with zsh, are they
also going to want to replace the /bin/sh manpage and expect that
replacement to be preserved?
> This isn't good enough -- I think you do need a preremove script. I've
> been trying to figure out why the no-preremove solution seems wrong, and
> came up with the following scenario: suppose bash is linked against an
> older libreadline, and the user upgrades both bash and libreadline to
> newer versions. /bin/sh will be a copy of the old version of bash, but
> after the upgrade it won't have the necessary DLLs. So, running the
> postinstall script (with "/bin/sh --version") will result in a "Can't
> locate DLL" popup, which should be a no-no in a postinstall script.
Thanks for thinking through these issues. I think we are closing in on
the best solution, and yes, I agree with your argument that bash should
keep its preremove script. Is there anything (in cygutils, perhaps) that
can request a replace-on-reboot if ln fails in the postinstall because
/bin/sh was in use during the upgrade? Then again, we already
recommend that all cygwin processes be stopped during an upgrade.
--
Eric Blake