echo expansion and POSIX compatibility RFE; bug report

[L Walsh]

Might I put forth a suggestion?

I would like to suggest that the "0" be required after a
"\" when expanding octal or hex values.

It would be consistent to allow hex values by using
"\0xHH", but it is confusingto POSIX compatible scripts
for "\1" to be accepted as an octal sequence.

Perhaps the existing behavior could be retained by:
--enable_broken_xpg? on config if it is needed, but I would
vote for it being "unsafe" (as in incompatible) as is.

I.e. -- a POSIX compatible script tried to use "echo "\\1" to
to get '\1' into an awk script.  Due to the more lax syntax,
"\1" was interpreted as a control-a under bash.

Technically "\xHH" doesn't conflict with any standard I'm
familiar with, but since \0 is already reserved as an octal
lead-in, having an "x" as the first "octal" digit shouldn't
cause any syntactic failure or semantic confusion.

Linda





___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Bash-3.1 Official Patch 14

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release: 3.1
Patch-ID: bash31-014

Bug-Reported-by: Mike Stroyan <[EMAIL PROTECTED]>
Bug-Reference-ID: <[EMAIL PROTECTED]>
Bug-Reference-URL: 
http://lists.gnu.org/archive/html/bug-bash/2006-02/msg4.html

Bug-Description:

The displayed search prompt is corrupted when using non-incremental
searches in vi and emacs mode if the prompt contains non-printing
characters or spans multiple lines.  The prompt is expanded more than
once; the second time without the escape sequences that protect non-
printing characters from the length calculations.

Patch:

*** ../bash-3.1-patched/lib/readline/display.c  Wed Nov 30 14:05:02 2005
--- lib/readline/display.c  Sat Feb 18 12:14:58 2006
***
*** 1983,1993 
   int pchar;
  {
int len;
!   char *pmt;
  
rl_save_prompt ();
  
!   if (saved_local_prompt == 0)
  {
len = (rl_prompt && *rl_prompt) ? strlen (rl_prompt) : 0;
pmt = (char *)xmalloc (len + 2);
--- 1998,2012 
   int pchar;
  {
int len;
!   char *pmt, *p;
  
rl_save_prompt ();
  
!   /* We've saved the prompt, and can do anything with the various prompt
!  strings we need before they're restored.  We want the unexpanded
!  portion of the prompt string after any final newline. */
!   p = rl_prompt ? strrchr (rl_prompt, '\n') : 0;
!   if (p == 0)
  {
len = (rl_prompt && *rl_prompt) ? strlen (rl_prompt) : 0;
pmt = (char *)xmalloc (len + 2);
***
*** 1998,2016 
  }
else
  {
!   len = *saved_local_prompt ? strlen (saved_local_prompt) : 0;
pmt = (char *)xmalloc (len + 2);
if (len)
!   strcpy (pmt, saved_local_prompt);
pmt[len] = pchar;
pmt[len+1] = '\0';
!   local_prompt = savestring (pmt);
!   prompt_last_invisible = saved_last_invisible;
!   prompt_visible_length = saved_visible_length + 1;
! }
  
prompt_physical_chars = saved_physical_chars + 1;
- 
return pmt;
  }
  
--- 2017,2033 
  }
else
  {
!   p++;
!   len = strlen (p);
pmt = (char *)xmalloc (len + 2);
if (len)
!   strcpy (pmt, p);
pmt[len] = pchar;
pmt[len+1] = '\0';
! }  
  
+   /* will be overwritten by expand_prompt, called from rl_message */
prompt_physical_chars = saved_physical_chars + 1;
return pmt;
  }
  
*** ../bash-3.1/patchlevel.hWed Jul 20 13:58:20 2005
--- patchlevel.hWed Dec  7 13:48:42 2005
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 13
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 14
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash shell parser bug

[Stephane Chazelas]

On Thu, Mar 16, 2006 at 08:28:28PM -0800, laura fairhead wrote:
> 
> 
> Hello,

Hi Laura,

> I just found a bug that affects a number of shells (pressumably the
> code there is from the same roots) in the parser.
> 
> The following code;
> 
> l='eval "$l"'
> eval "$l"
> 
> Which sets off an infinite recursion on 'eval', should result in an 
> infinite loop to be terminated by INT (doesnt' work) or at least
> end gracefully with an error "bash: out of memory". Instead the
> system has to kill the shell process because of SEGV fault.
[...]

It's the same with

f() { f; }; f

actually.

~$ bash -c 'f() { f; }; f'
zsh: segmentation fault  bash -c 'f() { f; }; f'
(139)~$ zsh -c 'f() { f; }; f'
zsh: segmentation fault  zsh -c 'f() { f; }; f'
(139)~$ ksh -c 'f() { f; }; f'
zsh: segmentation fault  ksh -c 'f() { f; }; f'
(139)~$ ash -c 'f() { f; }; f'
zsh: segmentation fault  ash -c 'f() { f; }; f'
(139)~$ gawk 'function f() { f() } BEGIN { f() }'
zsh: segmentation fault  awk 'function f() { f() } BEGIN { f() }'
(139)~$ perl -le 'sub f { f(); }; f'
zsh: killed perl -le 'sub f { f(); }; f'
(137)~$

For perl, it was probably the OOM killer, my Xserver was killed as well.


TCL:

~$ expect -c 'proc f {} { f }; f' 2>&1 | tail
"f "
(procedure "f" line 1)
invoked from within
"f "
(procedure "f" line 1)
invoked from within
"f "
(procedure "f" line 1)
invoked from within
"f"

The recursion limit seems to be 1000, there.

Same for:

expect -c 'set f {eval $f}; eval $f'

Same thing in python (limit 1000 as well) and ruby (limit seems higher).

~$ perl -le '$f = "eval \$f"; eval $f'

is still running but is slowly grabbing all the memory.

-- 
Stéphane


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Bash-3.1 Official Patch 12

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release: 3.1
Patch-ID: bash31-012

Bug-Reported-by: Alexander Kshevetskiy <[EMAIL PROTECTED]>
Bug-Reference-ID: <[EMAIL PROTECTED]>
Bug-Reference-URL: 
http://lists.gnu.org/archive/html/bug-bash/2006-01/msg00097.html

Bug-Description:

There is a parsing problem involving parentheses in assignment statements
that causes words to be terminated prematurely.

Patch:

*** ../bash-3.1/parse.y Fri Nov 11 23:14:18 2005
--- parse.y Wed Jan 25 14:55:18 2006
***
*** 3579,3583 
  all_digit_token = 0;
  compound_assignment = 1;
! #if 0
  goto next_character;
  #else
--- 3584,3588 
  all_digit_token = 0;
  compound_assignment = 1;
! #if 1
  goto next_character;
  #else
*** ../bash-3.1/patchlevel.hWed Jul 20 13:58:20 2005
--- patchlevel.hWed Dec  7 13:48:42 2005
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 11
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 12
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Grouped pipeline clobbering question

[Phillip Susi]

I'm a bit confused by the results I'm seeing with a pipeline to a 
group.  I was trying to parse a text file in such a way as the first n 
lines are passed straight through, and then a sed script is applied to 
the rest.  I thought I could do that with something like this:


cat file | ( head --lines=1 ; sed -e x )

I thought that head should consume the first line from the pipe, leaving 
the rest queued for sed to consume, but this does not seem to be the 
case.  It appears that the pipe either does not make it to sed or is 
empty when it does.  What am I doing wrong?





___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: echo "enhancement" leads to confused legacy script tools...

[Andreas Schwab]

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 Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Grouped pipeline clobbering question

[Paul Jarc]

Phillip Susi <[EMAIL PROTECTED]> wrote:
> cat file | ( head --lines=1 ; sed -e x )
>
> I thought that head should consume the first line from the pipe, leaving 
> the rest queued for sed to consume, but this does not seem to be the 
> case.

head may read an arbitrary amount of data from the pipe, although it
will print only as much as you tell it to.  To get the behavior you
want, you'll have to duplicate head's behavior in sed:

cat file | sed -e '1,10{p;d;}' -e x

And in this case, cat is unnecessary too:

sed -e '1,10{p;d;}' -e x < file


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Bash-3.1 Official Patch 13

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release: 3.1
Patch-ID: bash31-013

Bug-Reported-by: Bob Rossi <[EMAIL PROTECTED]>
Bug-Reference-ID: <[EMAIL PROTECTED]>
Bug-Reference-URL:

Bug-Description:

In some cases, readline will reference freed memory when attempting to
display a portion of the prompt.

Patch:

*** ../bash-3.1-patched/lib/readline/readline.c Mon Jul  4 22:29:35 2005
--- lib/readline/readline.c Fri Feb 17 22:54:22 2006
***
*** 282,287 
--- 282,288 
  {
FREE (rl_prompt);
rl_prompt = prompt ? savestring (prompt) : (char *)NULL;
+   rl_display_prompt = rl_prompt ? rl_prompt : "";
  
rl_visible_prompt_length = rl_expand_prompt (rl_prompt);
return 0;
*** ../bash-3.1/patchlevel.hWed Jul 20 13:58:20 2005
--- patchlevel.hWed Dec  7 13:48:42 2005
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 12
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 13
  
  #endif /* _PATCHLEVEL_H_ */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Readline-5.1 Official Patch 4

[Chet Ramey]

   READLINE PATCH REPORT
   =

Readline-Release: 5.1
Patch-ID: readline51-004

Bug-Reported-by: Mike Stroyan <[EMAIL PROTECTED]>
Bug-Reference-ID: <[EMAIL PROTECTED]>
Bug-Reference-URL: 
http://lists.gnu.org/archive/html/bug-bash/2006-02/msg4.html

Bug-Description:

The displayed search prompt is corrupted when using non-incremental
searches in vi and emacs mode if the prompt contains non-printing
characters or spans multiple lines.  The prompt is expanded more than
once; the second time without the escape sequences that protect non-
printing characters from the length calculations.

Patch:

*** ../readline-5.1-patched/display.c   Wed Nov 30 14:05:02 2005
--- display.c   Sat Feb 18 12:14:58 2006
***
*** 1983,1993 
   int pchar;
  {
int len;
!   char *pmt;
  
rl_save_prompt ();
  
!   if (saved_local_prompt == 0)
  {
len = (rl_prompt && *rl_prompt) ? strlen (rl_prompt) : 0;
pmt = (char *)xmalloc (len + 2);
--- 1998,2012 
   int pchar;
  {
int len;
!   char *pmt, *p;
  
rl_save_prompt ();
  
!   /* We've saved the prompt, and can do anything with the various prompt
!  strings we need before they're restored.  We want the unexpanded
!  portion of the prompt string after any final newline. */
!   p = rl_prompt ? strrchr (rl_prompt, '\n') : 0;
!   if (p == 0)
  {
len = (rl_prompt && *rl_prompt) ? strlen (rl_prompt) : 0;
pmt = (char *)xmalloc (len + 2);
***
*** 1998,2016 
  }
else
  {
!   len = *saved_local_prompt ? strlen (saved_local_prompt) : 0;
pmt = (char *)xmalloc (len + 2);
if (len)
!   strcpy (pmt, saved_local_prompt);
pmt[len] = pchar;
pmt[len+1] = '\0';
!   local_prompt = savestring (pmt);
!   prompt_last_invisible = saved_last_invisible;
!   prompt_visible_length = saved_visible_length + 1;
! }
  
prompt_physical_chars = saved_physical_chars + 1;
- 
return pmt;
  }
  
--- 2017,2033 
  }
else
  {
!   p++;
!   len = strlen (p);
pmt = (char *)xmalloc (len + 2);
if (len)
!   strcpy (pmt, p);
pmt[len] = pchar;
pmt[len+1] = '\0';
! }  
  
+   /* will be overwritten by expand_prompt, called from rl_message */
prompt_physical_chars = saved_physical_chars + 1;
return pmt;
  }
  

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: echo "enhancement" leads to confused legacy script tools...

[Paul Eggert]

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 POSIX+XSI hosts, so it should work with
Bash; so this is still a bug in either Autoconf or Squid, not in Bash.

There's a little history here.  POSIX 1003.2-1992 said that echo has
implementation-defined behavior if given any options, or if any
operands contain '\'.  This allows both traditional (echo -n) and
System V (backslash) interpretation.

SUSv2 came down squarely on the System V side.

But the BSD folks revolted on this, and POSIX 1003.1-2001 reverted to
the POSIX 1003.2-1992 spec, with the compromise of putting the System
V stuff into the XSI ghetto.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: echo "enhancement" leads to confused legacy script tools...

[Paul Eggert]

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 implementations.

POSIX requires that if an application wants an octal escape for (say)
the character with octal code 123, it must execute "echo '\0123'".  If
an application executes "echo '\123'" (without the "0"), POSIX says
that the results are implementation-defined.  Hence Bash can interpret
\123 as an octal escape as well, if it so chooses, and still conform
to POSIX+XSI.  A similar analysis applies to \x escapes.

For details, please see .

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 portability problem, one that is documented in the
Autoconf manual under "Limitations of Builtins").


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: echo "enhancement" leads to confused legacy script tools...

[Chet Ramey]

> 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 with the xpg_echo shell
option enabled, and in this case is conformant.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live Strong.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: echo "enhancement" leads to confused legacy script tools...

[Andreas Schwab]

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 conform to POSIX (in the default
configuration), since it also interprets -E and -e as options.

> 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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash