[PATCH] Re: missing sh.exe in coreutils

Brian Dessent brian@dessent.net
Mon Aug 15 12:59:00 GMT 2005


Eric Blake wrote:

> Also, the following patch to setup.exe will solve the problem of bash
> upgrades.  Since bash is guaranteed to exist if the user didn't unselect
> Base packages, but sh is not, we might as well always use /bin/bash as the

Ash is in 'base' too.

> shell to spawn postinstall scripts.  Since it is used as "bash -c script",
> it will obey #! and use the actual shell desired; it is really only bash
> that needs this patch, since bash is the only one that must not be spawned
> by /bin/sh if it is to update /bin/sh.

Is this a good idea?  This would fix the problem at hand but it doesn't
fix the problem in general.  It just makes it so that /bin/bash is
always in use, rather than /bin/sh.  To me the best solution for this
would be to use a .bat or .cmd file so that no Cygwin shell is in use,
but that has the problem of not being able to access Cygwin mounts.

Hmm..  

<ugly hack idea>
How about the package includes two postinstalls, 00bash.sh and
01bash.bat.  The sole purpose of 00bash.sh is to run first and overwrite
01bash.bat with one that contains the proper paths - the one shipped
would be a no-op.  Then setup would run 01bash.bat which would do the
copy with no cygwin processes active.  Example:

#!/bin/sh
echo "@COPY /Y `cygpath -d /bin/`bash.exe `cygpath -d /bin/`sh.exe" \
    >/etc/postinstall/01bash.bat

</ugly hack idea>

I admit that patching setup to use bash is a lot simpler, but (if it
works) the above would work without the user having to upgrade setup.

> - -  "/bin/sh.exe",
> - -  "/usr/bin/sh.exe",
> +  // Bash is guaranteed to exist, /bin/sh is not.  Besides,
> +  // upgrading /bin/sh requires that /bin/sh not be used.

Inline patches and non-detached gpg signing don't mix.

Brian



More information about the Cygwin-apps mailing list