From chet@nike.ins.cwru.edu Wed Apr 05 12:43:19 2000
Newsgroups: gnu.bash.bug
Subject: Bash-2.04.0-release patch 1
From: chet@nike.ins.cwru.edu (Chet Ramey)
Date: Wed, 5 Apr 2000 12:43:19 -0400

[This one was already posted as a reply to the original report]

			     BASH PATCH REPORT
			     =================

Bash-Release: bash-2.04.0-release
Patch-ID: bash204-001

Bug-Reported-by: pjw@edmc.net
Bug-Reference-ID: <20000329095218.5341.qmail@edmc.net>

Bug-Description:

        The +(pattern) operator does not work in all string modifying
        parameter expansions.  It works in ${parameter##word} but not
        ${parameter/pattern/string}.


Patch:

*** ../bash-2.04/subst.c	Tue Mar 14 10:42:02 2000
--- subst.c	Wed Mar 29 11:49:39 2000
***************
*** 2626,2630 ****
        return (*string == *pat);
      case '?':
!       return (*string == LPAREN ? 1 : (*string != '\0'));
      case '*':
        return (1);
--- 2626,2630 ----
        return (*string == *pat);
      case '?':
!       return (*pat == LPAREN ? 1 : (*string != '\0'));
      case '*':
        return (1);
***************
*** 2632,2636 ****
      case '!':
      case '@':
!       return (*string == LPAREN ? 1 : (*string == c));
      case '[':
        return (*string != '\0');
--- 2632,2636 ----
      case '!':
      case '@':
!       return (*pat == LPAREN ? 1 : (*string == c));
      case '[':
        return (*string != '\0');

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

From chet@nike.ins.cwru.edu Wed Apr 05 12:45:38 2000
Newsgroups: gnu.bash.bug
Subject: Bash-2.04.0-release patch 2
From: chet@nike.ins.cwru.edu (Chet Ramey)
Date: Wed, 5 Apr 2000 12:45:38 -0400

[This one was already posted as a reply to the original report]

			     BASH PATCH REPORT
			     =================

Bash-Release: bash-2.04.0-release
Patch-ID: bash204-002

Bug-Reported-by: Alessandro Suardi <asuardi@it.oracle.com>
Bug-Reference-ID: <38E1EE36.6F418BE0@it.oracle.com>

Bug-Description:

  I might have misunderstood the functionality, but the man page reads:

       ${parameter:?word}
              Display  Error  if  Null or Unset.  If parameter is
              null or unset, the expansion of word (or a  message
              to  that  effect if word is not present) is written
              to the standard error and the shell, if it  is  not
              interactive, exits.  Otherwise, the value of param<AD>
              eter is substituted.

If I source this one-liner, called "test.sh" and containing

  test ${9:?'generating a fatal error.'}

 by saying

 $ . ./test.sh

 what I get is that my _shell_ exits if $9 is unset. I tried even
 saying "set -i" in the one-liner itself or even explicitly saying
 bash -i then sourcing the one-liner, but my shell still exits.


Patch:

*** ../bash-2.04/subst.c	Tue Mar 14 10:42:02 2000
--- subst.c	Wed Mar 29 12:00:34 2000
***************
*** 4778,4782 ****
  	    {
  	      parameter_brace_expand_error (name, value);
! 	      return (interactive ? &expand_param_error : &expand_param_fatal);
  	    }
  	  else if (c != '+')
--- 4778,4782 ----
  	    {
  	      parameter_brace_expand_error (name, value);
! 	      return (interactive_shell ? &expand_param_error : &expand_param_fatal);
  	    }
  	  else if (c != '+')

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

From chet@nike.ins.cwru.edu Wed Apr 05 12:46:19 2000
Newsgroups: gnu.bash.bug
Subject: Bash-2.04.0-release patch 3
From: chet@nike.ins.cwru.edu (Chet Ramey)
Date: Wed, 5 Apr 2000 12:46:19 -0400

			     BASH PATCH REPORT
			     =================

Bash-Release: bash-2.04.0-release
Patch-ID: bash204-003

Bug-Reported-by: Tim Waugh <twaugh@redhat.com>
Bug-Reference-ID: <Pine.LNX.4.21.0003301702470.5966-100000@meme.surrey.redhat.com>

Bug-Description:

        The { character isn't quoted when using filename completion.

Patch:

*** ../bash-2.04/bashline.c	Fri Dec 31 15:03:51 1999
--- bashline.c	Fri Mar 31 11:12:46 2000
***************
*** 319,323 ****
  
    /* characters that need to be quoted when appearing in filenames. */
!   rl_filename_quote_characters = " \t\n\\\"'@<>=;|&()#$`?*[!:";
    rl_filename_quoting_function = bash_quote_filename;
    rl_filename_dequoting_function = bash_dequote_filename;
--- 319,323 ----
  
    /* characters that need to be quoted when appearing in filenames. */
!   rl_filename_quote_characters = " \t\n\\\"'@<>=;|&()#$`?*[!:{";	/*}*/
    rl_filename_quoting_function = bash_quote_filename;
    rl_filename_dequoting_function = bash_dequote_filename;

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

From chet@nike.ins.cwru.edu Mon Apr 17 12:40:06 2000
Newsgroups: gnu.bash.bug
Subject: Re-released Bash-2.04.0 patch 4
From: chet@nike.ins.cwru.edu (Chet Ramey)
Date: Mon, 17 Apr 2000 12:40:06 -0400

			     BASH PATCH REPORT
			     =================

[NOTE:  THIS IS A RE-RELEASED PATCH.  THE ORIGINAL PATCH HAD A FLAW THAT
	CAUSED POSIX-STYLE BRACE PATTERNS TO FAIL.]

Bash-Release: bash-2.04.0-release
Patch-ID: bash204-004

Bug-Reported-by: Akim Demaille <akim@epita.fr>
Bug-Reference-ID: <E12ZuUW-0004Ek-00@nostromo.lrde.epita.fr>

Bug-Description:

Bash behaves incorrectly on

case "/tmp" in
  [/\\]*) exit 0;;
esac
exit 1

The problem is with the bash `fnmatch':

	fnmatch ("/tmp", "[/\\\\]*]") fails to match, because after the `/'
	is matched, when brackmatch tries to skip the end of the
	characters list, it misses one of the `\', hence skips `\]' and
	then `*', and stops at `\0'.  Then it tries to fnmatch ("tmp", ""),
	which fails.

Patch:

*** ../bash-2.04/lib/glob/fnmatch.c	Wed Sep 22 16:31:02 1999
--- lib/glob/fnmatch.c	Wed Apr 12 17:00:18 2000
***************
*** 405,414 ****
  	  p += 4;
  	  if (collequiv (test, pc))
! 	    goto matched;
  	  else
  	    {
  	      c = *p++;
  	      if (c == '\0')
! 		return ((test == '[') ? savep : (char *)0);
  	      c = FOLD (c);
  	      continue;
--- 405,419 ----
  	  p += 4;
  	  if (collequiv (test, pc))
! 	    {
! /*[*/	      /* Move past the closing `]', since the first thing we do at
! 	         the `matched:' label is back p up one. */
! 	      p++;
! 	      goto matched;
! 	    }
  	  else
  	    {
  	      c = *p++;
  	      if (c == '\0')
! 		return ((test == '[') ? savep : (char *)0); /*]*/
  	      c = FOLD (c);
  	      continue;
***************
*** 447,451 ****
--- 452,461 ----
  	    { pc = isascii (test); p += 8; }
  	  if (pc)
+ 	    {
+ /*[*/	      /* Move past the closing `]', since the first thing we do at
+ 	         the `matched:' label is back p up one. */
+ 	      p++;
  	      goto matched;
+ 	    }
  	  else
  	    {
***************
*** 546,550 ****
--- 556,565 ----
  matched:
    /* Skip the rest of the [...] that already matched.  */
+ #if 0
    brcnt = (c != ']') + (c == '[' && (*p == '=' || *p == ':' || *p == '.'));
+ #else
+   c = *--p;
+   brcnt = 1;
+ #endif
    while (brcnt > 0)
      {

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

From chet@nike.ins.cwru.edu Tue May 02 13:03:34 2000
Newsgroups: gnu.bash.bug
Subject: Bash-2.04.0-release patch 5
From: chet@nike.ins.cwru.edu (Chet Ramey)
Date: Tue, 2 May 2000 13:03:34 -0400

			     BASH PATCH REPORT
			     =================

Bash-Release: bash-2.04.0-release
Patch-ID: bash204-005

Bug-Reported-by: amc@cs.berkeley.edu
Bug-Reference-ID: <m12jurx-000j6xC@arwen.cs.berkeley.edu>

Bug-Description:

    The behavior of the read command does not match the description of
    Word Splitting and IFS in the bash man page, and does not match the
    behavior of other shells (/bin/sh on Solaris, HP-UX, and Digital
    Unix).  Consider the following commands:

    sh-2.04$ IFS='() '
    sh-2.04$ read a b c d
    one (two) three four
    sh-2.04$ echo "$a"
    one
    sh-2.04$ echo "$b"
    
    sh-2.04$ echo "$c"
    two
    sh-2.04$ echo "$d"
    three four

    Apparently, the first space and the left parenthesis in the input
    string "one (two) three four" are being considered two separate
    delimiters (which is wrong), while the second space and right
    parenthesis are being considered a single delimiter (which is
    correct).  In other shells the variables a/b/c/d get the values
    one/two/three/four respectively.

Patch:

*** ../bash-2.04/subst.c	Tue Mar 14 10:42:02 2000
--- subst.c	Fri Apr 28 14:41:59 2000
***************
*** 1445,1449 ****
    WORD_DESC *t;
    char *current_word, *s;
!   int sindex, sh_style_split;
  
    if (!string || !*string)
--- 1445,1449 ----
    WORD_DESC *t;
    char *current_word, *s;
!   int sindex, sh_style_split, whitesep;
  
    if (!string || !*string)
***************
*** 1512,1515 ****
--- 1512,1518 ----
        free (current_word);
  
+       /* Note whether or not the separator is IFS whitespace, used later. */
+       whitesep = string[sindex] && spctabnl (string[sindex]);
+ 
        /* Move past the current separator character. */
        if (string[sindex])
***************
*** 1520,1523 ****
--- 1523,1533 ----
        while (string[sindex] && spctabnl (string[sindex]) && issep (string[sindex]))
  	sindex++;
+ 
+       /* If the first separator was IFS whitespace and the current character is
+ 	 a non-whitespace IFS character, it should be part of the current field
+ 	 delimiter, not a separate delimiter that would result in an empty field.
+ 	 Look at POSIX.2, 3.6.5, (3)(b). */
+       if (string[sindex] && whitesep && issep (string[sindex]) && !spctabnl (string[sindex]))
+ 	sindex++;
      }
    return (REVERSE_LIST (result, WORD_LIST *));
***************
*** 1535,1539 ****
    register char *s;
    char *current_word;
!   int sindex, sh_style_split;
  
    if (!stringp || !*stringp || !**stringp)
--- 1545,1549 ----
    register char *s;
    char *current_word;
!   int sindex, sh_style_split, whitesep;
  
    if (!stringp || !*stringp || !**stringp)
***************
*** 1574,1577 ****
--- 1584,1590 ----
      *endptr = s + sindex;
  
+   /* Note whether or not the separator is IFS whitespace, used later. */
+   whitesep = s[sindex] && spctabnl (s[sindex]);
+ 
    /* Move past the current separator character. */
    if (s[sindex])
***************
*** 1583,1586 ****
--- 1596,1606 ----
      sindex++;
  
+   /* If the first separator was IFS whitespace and the current character is
+      a non-whitespace IFS character, it should be part of the current field
+      delimiter, not a separate delimiter that would result in an empty field.
+      Look at POSIX.2, 3.6.5, (3)(b). */
+   if (s[sindex] && whitesep && issep (s[sindex]) && !spctabnl (s[sindex]))
+     sindex++;
+ 
    /* Update STRING to point to the next field. */
    *stringp = s + sindex;

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

From chet@nike.ins.cwru.edu Tue May 02 13:05:11 2000
Newsgroups: gnu.bash.bug
Subject: Bash-2.04.0-release patch 6
From: chet@nike.ins.cwru.edu (Chet Ramey)
Date: Tue, 2 May 2000 13:05:11 -0400

			     BASH PATCH REPORT
			     =================

Bash-Release: bash-2.04.0-release
Patch-ID: bash204-005

Bug-Reported-by: Ken Pizzini <ken@halcyon.com>
Bug-Reference-ID: <20000413222502Z174183-10836+8@pulsar.halcyon.com>

Bug-Description:

        The new prefix expansion operator ${!prefix*} is nice, but its
        sibling ${!prefix@} is not documented in the man page, and the
        behavior of "${prefix@}" seems wrong.  The expansions of
        ${!prefix*} and ${!prefix@} appear to be correctly the same,
        but the expansions of "${!prefix*}" and "${!prefix@}" appear to
        be incorrectly the same.  I would expect the behavior of
        "${!prefix@}" to be analogous to the expansion of "$@", where
        the individual expansions maintain identities as seperate
        arguments.

Patch:

	The ${!prefix@} expansion is still undocumented, as it is in ksh93,
	from whence I cribbed it, but it now behaves analogously to "$@"
	when double-quoted.

*** ../bash-2.04/subst.c	Tue Mar 14 10:42:02 2000
--- subst.c	Fri Apr 28 10:49:06 2000
***************
*** 4600,4604 ****
        x = all_variables_matching_prefix (temp1);
        xlist = argv_to_word_list (x, 1, 0);
!       temp = string_list_dollar_star (xlist, quoted);
        free (x);
        free (xlist);
--- 4628,4641 ----
        x = all_variables_matching_prefix (temp1);
        xlist = argv_to_word_list (x, 1, 0);
!       if (string[sindex - 2] == '*')
! 	temp = string_list_dollar_star (xlist, quoted);
!       else
! 	{
! 	  temp = string_list_dollar_at (xlist, quoted);
! 	  if ((quoted & (Q_HERE_DOCUMENT|Q_DOUBLE_QUOTES)) && quoted_dollar_atp)
! 	    *quoted_dollar_atp = 1;
! 	  if (contains_dollar_at)
! 	    *contains_dollar_at = 1;
! 	}
        free (x);
        free (xlist);


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

From chet@nike.ins.cwru.edu Tue May 02 13:05:41 2000
Newsgroups: gnu.bash.bug
Subject: Bash-2.04.0-release patch 7
From: chet@nike.ins.cwru.edu (Chet Ramey)
Date: Tue, 2 May 2000 13:05:41 -0400

			     BASH PATCH REPORT
			     =================

Bash-Release: bash-2.04.0-release
Patch-ID: bash204-007

Bug-Reported-by: jsberg@jsberg1.cap.bnl.gov
Bug-Reference-ID: <200003301604.LAA18064@jsberg1.cap.bnl.gov>

Bug-Description:

        Consider the following script

                #!/bin/sh -
                echo "a^@b"
                echo "`cat test.in`"

        With the input file test.in containing
                
                c^@d
        
        The string "^@" should be replaced with the null character. 
        
        "sh test.sh | od -a" gives
                
                0000000   a  nl   b  nl   c  nl
                0000006
                
        First of all, I wouldn't think that the replacement of the
        null character by a newline in the first command's output is
        correct.  Secondly, and more importantly, the loss of
        everything after the first null in the command substitution is
        a problem.


Patch:

(All other shells I tested except ksh93 appear to ignore NUL bytes on
read.  ksh93 makes them cause a syntax error.)

*** ../bash-2.04/subst.c	Tue Mar 14 10:42:02 2000
--- subst.c	Fri Apr 28 10:49:06 2000
***************
*** 3305,3308 ****
--- 3325,3336 ----
        c = *bufp++;
  
+       if (c == 0)
+ 	{
+ #if 0
+ 	  internal_warning ("read_comsub: ignored null byte in input");
+ #endif
+ 	  continue;
+ 	}
+ 
        /* Add the character to ISTRING, possibly after resizing it. */
        RESIZE_MALLOCED_BUFFER (istring, istring_index, 2, istring_size, DEFAULT_ARRAY_SIZE);
*** ../bash-2.04/parse.y	Tue Feb 22 13:12:03 2000
--- parse.y	Fri Apr 28 10:49:38 2000
***************
*** 1413,1418 ****
        QUIT;
  
        if (c == 0)
! 	continue;
  
        /* If there is no more input, then we return NULL. */
--- 1413,1424 ----
        QUIT;
  
+       /* Ignore null bytes in input. */
        if (c == 0)
! 	{
! #if 0
! 	  internal_warning ("read_a_line: ignored null byte in input");
! #endif
! 	  continue;
! 	}
  
        /* If there is no more input, then we return NULL. */
***************
*** 1605,1613 ****
  	clearerr (stdin);
  
!       while (c = yy_getc ())
  	{
  	  /* Allow immediate exit if interrupted during input. */
  	  QUIT;
  
  	  RESIZE_MALLOCED_BUFFER (shell_input_line, i, 2, shell_input_line_size, 256);
  
--- 1611,1629 ----
  	clearerr (stdin);
  
!       while (1)
  	{
+ 	  c = yy_getc ();
+ 
  	  /* Allow immediate exit if interrupted during input. */
  	  QUIT;
  
+ 	  if (c == '\0')
+ 	    {
+ #if 0
+ 	      internal_warning ("shell_getc: ignored null byte in input");
+ #endif
+ 	      continue;
+ 	    }
+ 
  	  RESIZE_MALLOCED_BUFFER (shell_input_line, i, 2, shell_input_line_size, 256);
  
***************
*** 1633,1636 ****
--- 1649,1653 ----
  	    }
  	}
+ 
        shell_input_line_index = 0;
        shell_input_line_len = i;		/* == strlen (shell_input_line) */

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/

