Yes, this change was intended, upstream writes:
"changed from 3.1 to 3.2, for Posix conformance. `echo -e' (and the
corresponding xpg_echo shell option) now conform to the POSIX standard
and accept 0-3 octal digits after a (required) leading `\0'.
The xpg_echo and `echo -e' code should be identical. There are lots
of ways to indicate that backslash escapes should be interpreted --
maybe too many -- but when they are, they should behave consistently.
This is why portable applications should use printf."
Ola Lundqvist writes:
> Thanks a lot! We'll see what the bash maintaier says about this.
>
> Best regards,
>
> // Ola
>
> On Mon, Apr 28, 2008 at 10:14:39AM +0200, Lucas Nussbaum wrote:
> > clone 477969 -1
> > reassign -1 bash
> > found -1 3.2-2
> > notfound -1 3.1dfsg-9
> > retitle -1 bash: echo -e no longer interprets \nnn
> > thanks
> >
> > On 27/04/08 at 23:00 +0200, Ola Lundqvist wrote:
> > > Hi Lucas
> > >
> > > Thanks for the report.
> > >
> > > However I do not understand the error code in this case. It complains
> > > about
> > > a stray '\' but there is no '\' character in that file. Have you seen this
> > > before and know what the problem is?
> >
> > drivers.c contains:
> > static const CALDRIVER *driver_registry\133\135 = {
> > &icap_driver,
> > &mstore_driver,
> > NULL
> > };
> >
> > note the \133\135, which isn't there after unpacking the sources.
> >
> > It seems to be that configure is at fault here:
> > rm --force drivers.c
> > echo -e 'static const CALDRIVER *driver_registry\133\135 = {' > drivers.c
> >
> > This is caused by a change in bash 3.2. With bash 3.1:
> > *** [EMAIL PROTECTED]:~$ printf '\133\n'
> > [
> > *** [EMAIL PROTECTED]:~$ echo -e '\133'
> > [
> >
> > With bash 3.2:
> > grelon-62:~# printf '\133\n'
> > [
> > grelon-62:~# echo -e '\133'
> > \133
> >
> > This seems to be on purpose (the man page was updated as well), but I'm not
> > sure if it's correct.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
