[PATCH] Two fixes for setup postinstall handling.

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Sun Aug 10 15:30:00 GMT 2008

On Sun, Aug 10, 2008 at 02:21:48PM +0100, Dave Korn wrote:
>In case it's controversial, I thought I'd post these patches before
>committing anything.  The two hunks I've included in one patchfile here
>are in fact separate and orthogonal, I just posted them in one file for
>The first hunk finds if bash is in the list of packages that have
>scripts to run and swaps it with the first entry if so.  You may feel
>it's crude, but it's also does-what-it-says-on-the-tin, and it's sane:
>we can't possibly run postinstall scripts without a working shell, the
>postinstall script for the shell is what guarantees we have what counts
>as "a working shell" for that purpose, so why not just deliberately say
>"Hey, we have to do this first and we know we have to do it first so
>let's just do it first"?

If this is necessary, I don't like the idea of special casing bash.
Can't we add a keyword to setup.ini so this could be configurable?

>  The second hunk checks for the return code from bash that means 'bad
>interpreter', i.e. when it has been unable to invoke the executable listed
>after a shebang.  We can't know in the general case of an error during
>execution whether the script run and/or how close it got to completion
>before it failed, but in this one specific case we can know for absolute
>certain that it didn't run not even a little bit, so let's do ourselves a
>favour and not mark it done.  I think that means that people who have
>failures could just re-run and click straight through setup.exe and get the
>scripts to run without having to set everything to "Reinstall" as is
>currently the case.  I'm not mad keen on a hardcoded 126 in there, but AFAI
>could find out there's no public header with bash error codes in it -
>someone please correct me if they know better.
>  The first hunk could be obviated by doing away with postinstall scripts
>for bash, but it a) is perhaps an easier change than respinning a fresh bash

?  How is patching, reviewing the patch, rebuilding, and releasing setup.exe 
easier than Eric releasing a new version of bash which just installs sh.exe

>b) is defensive programming - it's always going to be the case that, if
>there are any scripts needed to install the shell, they should be the
>very first thing we do, and this means that should a situation ever
>arise in the future where we find ourselves needing bash postinstall
>scripts, they will just work and we won't regress to the situation we
>find ourselves in now.

Sorry but I'm not yet convinced that this is necessary.


More information about the Cygwin-apps mailing list