This is the mail archive of the cygwin 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: BUG: bash 3.0-7 breaks rebaseall


On Wed, 13 Jul 2005, Eric Blake wrote:

> According to Brian Dessent on 7/13/2005 7:21 PM:
> > Thanks for the report, but this has already been noted and discussed
> > recently in other threads.  Several solutions have been proposed but I
> > think the jury is still out on how to handle it.
> >
> > The main issue is that no matter how you implement the 'rebaseall'
> > concept, you still won't be able to run it from a standard bash command
> > prompt and have it modify the in-use DLLs.  I think statically linking
> > bash or providing a second version of bash that is statically linked
> > have both been vetoed.
>
> Actually, I am against a statically linked /bin/sh as bash, because
> /bin/sh should not be any less full-featured than /bin/bash, or we are no
> better off than having ash again with regards to the sh != bash complaints
> on the list.  But I am not entirely opposed to a statically linked
> /usr/sbin/sh, a statically-linked version of bash with all interactive
> features stripped (ie. no aliases, no history, no syntax extensions, ...).
>  Normal PATHs do not put sbin at the front (or maybe I could name it
> /usr/sbin/bash-lite to be explicit and unique).  But rebaseall would then
> have a known good static shell, and still break the dependence on ash.  By
> the way, since sbin is not mounted by default, would such a reduced shell
> belong better as /sbin/sh or /usr/sbin/sh?

This must be by now approximately the third iteration of the discussion.
A separate statically-linked shell as the interpreter shell for rebaseall
will not work, simply because that will need to be invoked from another
shell (which would most likely be bash).  So nothing's gained, since the
bash process will still be running.

Let's face it, rebaseall as it's written now relies on there being no DLLs
loaded (read: locked) besides cygwin1.dll.  If there are, it fails.
Running rebaseall from bash (as it currently stands) will cause other DLLs
to be in memory -- thus, rebaseall cannot be run from bash.  If rebaseall
is invoked from a DOS shell as 'someshell rebaseall', then 'someshell'
needs to be statically linked to every library except cygwin1.dll.

If we go to the trouble of compiling a special shell for rebaseall, we
might as well rewrite it in C, with about as much investment of time and
effort.  Since, as was mentioned before, automatic selection of image
bases won't work, so maybe it's time to bite the bullet and write it now.
	Igor
P.S. We don't have anything in /sbin now, and I don't think this is the
time to start.
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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