-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Brian Dessent on 8/15/2005 7:02 AM: > >>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.
But who really WANTS to run postinstall scripts with /bin/ash, when it is non-POSIX compliant? On the other hand, it wouldn't be too hard to replace /bin/sh with /bin/ash as the search order in scripts.cc, rather than deleting /bin/sh altogether; either way the patch is a two-liner. > >>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. Having /bin/sh in use prevents /etc/postinstall/00bash.sh from upgrading /bin/sh, leading to version mismatch between /bin/sh and /bin/bash. But so far, the only time that having /bin/bash in use is a problem is if /bin/sh is hard-linked to /bin/bash; which is not the case for normal installs. So it can't hurt anything, and will alleviate the version mismatch problem that currently exists. > > 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> Better than anything I've come up with so far. I was considering an opposite approach - have /etc/postinstall/00bash.bat, which uses the knowledge that it is called from /, so it can use /bin/cygpath to resolve /etc/profile.d, then call /bin/bash -c /etc/profile.d/00bash.sh (rather than calling COPY from the .bat). Your hack idea would make the cygpath part much easier (use the 00.sh to set up the 01.bat, rather than trying to pipe commands around in batch programming), but still involves a .bat script. Does setup.exe really support multiple postinstalls from the same package? > Inline patches and non-detached gpg signing don't mix. Yeah, I'm aware; I just forget that at times. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDAJYX84KuGfSFAYARArHgAKCkXkpXIysptUkmF4cPmWl9XnqncgCfQEmJ lXK2JfrELiftjucpV87TTug= =ojrv -----END PGP SIGNATURE-----
