On Sun, Dec 16, 2018 at 10:14:37PM -0500, Earnie wrote:
> The question that needs answered is what issue was being resolved by
> the addition of the -r? The resolution here may need filters based
> on the build host.
I authored the change myself in May this year (as we only recently
started usin
On 12/16/2018 4:53 PM, John Ericson wrote:
In GNU bash, -r, turns off special escape code handling. Configs don't
have escape codes so it makes sense do this. Without that flag then,
valid input stays valid, but some invalid input becomes valid too. So
skipping that is unfortunate for GNU bash,
In GNU bash, -r, turns off special escape code handling. Configs don't have escape codes so it makes sense do this. Without that flag then, valid input stays valid, but some invalid input becomes valid too. So skipping that is unfortunate for GNU bash, but certainly makes sense for whatever odd she
Ben Elliston wrote:
> > The same thing with traces shows where the problem occurs:
>
> [...]
>
> > + break
> > IFS=-
> > + read -r field1 field2 field3 field4
> > sun4
> > ../build-aux/config.sub: -r: is not an identifier
>
> I don't know why we don't just drop -r in both instances in
> config
On Sun, Dec 16, 2018 at 10:03:27AM +0100, Bruno Haible wrote:
> The same thing with traces shows where the problem occurs:
[...]
> + break
> IFS=-
> + read -r field1 field2 field3 field4
> sun4
> ../build-aux/config.sub: -r: is not an identifier
I don't know why we don't just drop -r in both
Hi,
This is a show-stopper: The current config.sub (since 2018-05-06) prevents
packages from being configured on Solaris 10.
I am testing the current grep snapshot
https://meyering.net/grep/grep-3.1.48-7eea.tar.xz
on Solaris 10/sparc, and the configuration fails like this:
-
