Chet Ramey wrote:
The remaining consideration is whether or not there's a significant
body of scripts out there that rely on the current behavior. If there
isn't, I would strongly consider the change to require a leading `0'
in octal constants. I don't think that \x introducing hex constants
is
Hello,
On Fri, Mar 31, 2006 at 01:28:37PM -0500, Chet Ramey wrote:
> [...] I don't think that \x introducing hex constants
> is as big a problem (it may not be a problem at all).
well, that makes `\x' yet another sequence which can surprise the user:
it changes to something else, _if_ it is fol
> I'm willing to try the CVS versions of autoconf later on, but
> can't promise when I'll get to it. I can confirm, though, that
> the bug I'm running into only happened when I rebuilt bash and
> specified the --enable_xpg_default option.
You would have seen the same results had you specifi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 3/20/2006 11:58 PM:
>>> There's a little history here. POSIX 1003.2-1992 said that echo has
>>> implementation-defined behavior if given any options, or if any
>> Are you sure about "any option"? The current spec only talk
Hello everybody,
* Linda W wrote on Mon, Mar 20, 2006 at 10:16:44PM CET:
> Henrik Nordstrom wrote:
> >Note: As far as I can tell the echo tests in the configure script
> >generated by autoconf-2.59 tests for quite many things but not \digit as
> >far as I can tell. I have not yet looked into the C
Andreas Schwab <[EMAIL PROTECTED]> writes:
>> There's a little history here. POSIX 1003.2-1992 said that echo has
>> implementation-defined behavior if given any options, or if any
>
> Are you sure about "any option"? The current spec only talks about -n.
Yes, I have the printed copy of POSIX 1
Henrik Nordstrom wrote:
Note: As far as I can tell the echo tests in the configure script
generated by autoconf-2.59 tests for quite many things but not \digit as
far as I can tell. I have not yet looked into the CVS version.
Regards
Henrik
---
Sorry, haven't been involved too much on t
Linda W <[EMAIL PROTECTED]> writes:
> I believe bash is broken in regards to using "any" number after
> "\" as an octal value. The shell specifications require the leading
> zero for an octal constant
The specification does not _require_ it, it allows it. Any other use of
the backslash results
tis 2006-03-21 klockan 17:32 +0100 skrev Ralf Wildenhues:
> To finish this up for squid: Please install the patches below (it'd be
> nice if you could feed back the cppunit related ones to their upstream),
> install the file lib/cppunit-1.10.0/config/ax_prefix_config_h.m4 from
> http://autoconf-a
* Ralf Wildenhues wrote on Tue, Mar 21, 2006 at 05:02:49PM CET:
>
> The issue is not in Autoconf, but in the macro AC_CREATE_PREFIX_CONFIG_H
[...]
> I will look into that, and post an update.
To finish this up for squid: Please install the patches below (it'd be
nice if you could feed back the c
sön 2006-03-19 klockan 12:57 -0800 skrev Paul Eggert:
> Autoconf deals with shells that do not conform to XSI, and where the
> results are implementation-defined if there's a backslash anywhere in
> the string, so to some extent this point is moot for Autoconf (though
> it's undeniably a portabili
Henrik Nordstrom wrote:
lör 2006-03-18 klockan 14:15 -0800 skrev Linda W:
Bash added the "feature" to allow dropping of the leading
"0", accepting strings: "\0nnn", "\nnn", and "\xHH". I'm guessing that
most bash users run in a shell that has expansion turned off by default or
this wo
* Ralf Wildenhues wrote on Tue, Mar 21, 2006 at 05:02:49PM CET:
> FWIW, are there _any_ other shells that do not output \1 with
> echo "\\1"
> except for bash-3.0-with-xpg-echo?
Ouch. Never mind that stupid question, please.
___
Bug-bash mailing lis
Paul Eggert <[EMAIL PROTECTED]> writes:
> Andreas Schwab <[EMAIL PROTECTED]> writes:
>
>> But note that bash interprets -n as an option, which is not compliant with
>> XSI.
>
> Bash doesn't claim conformance to XSI, so that's OK as far as Bash is
> concerned.
I understand that. It doesn't even c
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
> > Hence Bash can interpret \123 as an octal escape as well, if it so
> > chooses, and still conform to POSIX+XSI.
>
> But note that bash interprets -n as an option, which is not compliant with
> XSI.
Bash claims XSI conformance when in posix mode wit
Linda W <[EMAIL PROTECTED]> writes:
> I believe bash is broken in regards to using "any" number after
> "\" as an octal value. The shell specifications require the leading
> zero for an octal constant
I'm afraid this is backwards. This POSIX+XSI requirement constrains
applications, not implemen
Andreas Schwab <[EMAIL PROTECTED]> writes:
> But note that bash interprets -n as an option, which is not compliant with
> XSI.
Bash doesn't claim conformance to XSI, so that's OK as far as Bash is
concerned. Autoconf (and I assume Squid) is supposed be portable to
all POSIX hosts, not merely POS
Paul Eggert <[EMAIL PROTECTED]> writes:
> Hence Bash can interpret \123 as an octal escape as well, if it so
> chooses, and still conform to POSIX+XSI.
But note that bash interprets -n as an option, which is not compliant with
XSI.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE
Henrik Nordstrom <[EMAIL PROTECTED]> writes:
> sön 2006-03-19 klockan 12:57 -0800 skrev Paul Eggert:
>
>> Autoconf deals with shells that do not conform to XSI, and where the
>> results are implementation-defined if there's a backslash anywhere in
>> the string, so to some extent this point is moo
19 matches
Mail list logo
