[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