This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Re: missing sh.exe in coreutils


-----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             ebb9@byu.net
-----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-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]