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


On Mon, 15 Aug 2005, Brian Dessent wrote:

> Eric Blake wrote:
>
> > 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.
>
> Well, since most postinstall scripts contain a shebang, the actual
> interpreter that setup spawns is irrelevent, since it will then try to
> run whatever interpreter the script calls for.

True, but all we need to make sure of is that the interpreter that setup
spawns is the one that's an actual file distributed inside a tarball (or
pre-existing on the system), rather than one created by a postinstall
script.

> > 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.
>
> Yes, for right now it's a moot point.  I just mean that in general it
> doesn't fix the problem, just shifts it.
>
> I do agree about the search order however.  Setup should probably try
> bash, then sh, then ash.  Any objections to this - Max, Igor, anyone
> that knows anything about setup?

I'd say "bash, then ash, then sh".  We know bash and ash are in "Base", so
they would most likely be found, anyway, so "sh" is superfluous.  Or just
bite the bullet and say that "no bash = no install", and only use bash as
the interpreter.  Opinions?

> > 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?
>
> Setup does support .bat files, and does support multiple postinstall
> scripts in a package.

Yes, since we know the package contents when running them.  It's the
preremove scripts that are a problem (since there's currently no way to
associate them with the package other than by name).

> However, I just noticed something that will make life a lot easier - it
> sets the CYGWINROOT environment variable when running a script.  This
> means that we should be able to just have a single .bat file containing
>
> @copy /y %CYGWINROOT$\bin\bash.exe %CYGWINROOT%\bin\sh.exe
>
> This needs testing, but it should work.

Yep, it should (if you replace the '$' by a '%' in the first
'%CYGWINROOT$' >:-D).
	Igor
-- 
				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


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