This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Eric Blake wrote:
> > 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.
:-D
> 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?
I'd say you should only replace it if it belonged to ash. But it also
seems to me that the whole postinstall process is getting too complex,
and calls for some sort of helper apps.
> > 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?
Not that I know of, but if there were such a tool, cygutils is where it
would belong, IMO. It would seem that something like the following would
be the right idiom for this:
/bin/ln -f /bin/bash /bin/sh || /bin/replace-on-reboot -f /bin/bash /bin/sh
<RANT>
However, the whole replace-on-reboot issue has a few consequences that
are, IMO, undesirable (such as a reboot). One of the things I've been
meaning to do is change setup to notify the user (in interactive mode, of
course) that some processes are running, and give the user an option of
stopping the relevant processes and retrying the update (or choosing to
"do the default thing and replace-on-reboot"). When (and if) I get to it,
the postinstall scripts should be able to offer the same options.
There's also the question of notification ("Some in-use files were
replaced, please reboot") -- whatever mechanism is used in postinstall
scripts, it would be useful to communicate the replace-on-reboot usage to
setup. I also wonder if setup should be able to tell the postinstall
scripts whether it's running in interactive mode.
</RANT>
> Then again, we already recommend that all cygwin processes be stopped
> during an upgrade.
Yes, but that doesn't mean that the setup process shouldn't be robust
enough to handle users who don't follow directions. :-)
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT