bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bash vs. sh


From: Jim Meyering
Subject: Re: Bash vs. sh
Date: Tue, 22 Apr 2008 11:42:31 +0200

"Joel E. Denny" <address@hidden> wrote:
> Coreutils maintainers,
>
> It appears that Bison's bootstrap script is occasionally sync'ed against
> Coreutils'.  Paul Hilfinger, one of the Bison developers, recently made
> the discovery quoted below, which I figure might also be relevant to
> Coreutils.
>
> On Fri, 4 Apr 2008, Joel E. Denny wrote:
>
>> On Wed, 26 Mar 2008, Paul Hilfinger wrote:
>>
>> > The bootstrap file is headed
>> >
>> >     #! /bin/sh
>> >
>> > However, it contains lines such as
>> >
>> >      if ! "$SHA1SUM" -c --status "$cksum_file" < "$new_po" >  /dev/null; 
>> > then
>> >
>> > and
>> >
>> >      if ! test -d "$dst_dir"; then
>> >
>> > In a standard Solaris 10 installation, /bin/sh does not recognize the
>> > '!' command.  I had to fix this by changing the shell used by
>> > bootstrap to /bin/bash.
>>
>> Thanks for the report.  I don't know whether Bison should switch to
>> /bin/bash or just weed out Bash-specific code.
>
> I just checked the Coreutils git repository, and it appears that similar
> constructs are still present in its latest bootstrap version.  I don't
> know whether there are other Bash-specific constructs present.
>
> It appears that Coreutils, like Bison, requires repository users to
> install Autotools, Gettext, etc, so it's probably not too much to ask them
> to install Bash as well.  However, it's not clear to me if we should
> assume Bash can then be found at /bin/bash.  What do you think?

Hi Joel,

Thanks for forwarding that.
My first reflex was to "fix" bootstrap not to use that construct,
but there are too many occurrences, and that's a slippery slope.
Besides, it's easy to work around.

I'll probably change the instructions in README-hacking to mention
that you may have to run "bash ./bootstrap" rather than

        $ ./bootstrap

if your system's /bin/sh is substandard.
Plus, maybe be a test to detect the broken shell and to warn you
that you need to invoke the script differently.

An alternative is to encumber bootstrap with shell-selection
code and make it re-exec itself using a sufficiently functional shell.
But that too may fail, so I don't see the point.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]