/bin/sh vs. /bin/bash (was: RE: Not quite (Cygwin build_alias bug hunt))

[Bogdan Vacaliuc]

Hi Ralf,

On Sunday, September 19, 2004 2:12 AM, Ralf Corsepius wrote:
> On Sat, 2004-09-18 at 19:26, Bogdan Vacaliuc wrote:
> 
> > I should also mention, that I haven't played any games with 
> sh.exe and 
> > bash.exe in my setup.  Since configure will automatically chooses 
> > bash.exe to run the salient parts.
>
> This is not true. configure will choose /bin/sh unless you 
> override SHELL or CONFIG_SHELL.

Alright.  Let me rephrase, then:

"Under the context of rtems under cygwin, I have observed that configure will choose /bin/bash (instead of /bin/sh) when running
salient parts of the configure scripts."

As evidence of this I provide the following.

When configure runs (under rtems), it produces output such as:

    configure: running /bin/bash '.../configure' ...

If one were to grep for /bin/bash and /bin/sh in the resulting logs, one would not find a single instance of /bin/sh, but many
instances of /bin/bash.

In the shell that the above experiments are done, SHELL=/bin/sh and CONFIG_SHELL is undefined.

*Furthermore* if one replaces /bin/sh.exe with /bin/bash.exe, then the configure scripts produce output such as:

    configure: running /bin/sh '.../configure' ...

as a further testament of the intelligence of the configure scripts.

---

My point was two fold:

1) The rtems configure scripts appear to "take care of themselves" in terms of selecting an appropriate shell.

2) Exchanging /bin/sh.exe for /bin/bash.exe can introduce problems in other build systems under cygwin not related to rtems.

---

Now, the argument could be made that doing #2 above could expose deficiencies in those systems which deserve to be found and fixed.
I would agree with you on that point; however as I understand it, you are not making that argument here.

---

On Sunday, September 19, 2004 2:27 AM, Ralf Corsepius wrote:
> > It would be nice to address the part of the rtems document that says 
> > you should copy /bin/bash.exe into /bin/sh.exe.  Either to determine 
> > that 'yes, it is necessary, and this is why... [so that the guilty 
> > piece of software could be fixed]', or 'no, we don't need to do that 
> > anymore'.
> 
> I am opposed to do this, for one reason: All such statements are only temporarily valid.

Do you mean that 'for any given build system /bin/sh is only temporarily valid as a suitable shell'?  And thus, correspondingly,
/bin/bash is universially valid as a suitable shell?

I suppose, in that case, you are right.  However, is the solution to copy /bin/bash to /bin/sh universally valid as well?  I think
not.  We have seen evidence in which that procedure introduced errors in the build system itself.

It seems to me that autoconf (or rtems' configuration and use of it) have already addressed the issue and provided a mechanism to
select /bin/bash as the shell to use.

Do you think this is inadequate?  Do you think that the makefiles will use /bin/sh implicitly and therefore break?

> > My hunch is that with the Cygwin of today, it is not needed anymore.
>
> Are you trying to say Cygwin's ash is sufficent to build RTEMS?
> 
> If yes, the corresponding sentence in RTEMS docs should be purged.

No, I couldn't be saying that, because it is untestable (by me, within reasonable time constraints).  What I was trying to say was
that any special treatment of /bin/sh and /bin/bash in building rtems under cygwin (as it exists on Sept. 19, 2004) may be
unnecessary.

At the very least, one should add a statement to the RTEMS docs to the effect that "Performing this (exchange of /bin/sh.exe with
/bin/bash.exe) procedure may cause other build scripts to fail; for example: building the cygwin bash sources via
/usr/src/bash-2.05b-16.sh".


Kind Regards,

-bogdan