> 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