Re: Fwd: Re: Bash-3.1.17 gets lost looking for end of string in certain contexts

2006-05-04 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Richard on 5/3/2006 7:50 PM:
   Just curious: why is it that your version displays 6 within parenthesis,
 whereas mine displays 2?

The number in parenthesis matches the number of times you have rebuilt in
your local tree (also encoded in the ./.build file in the top level of
your build directory).  Some distributions use it to encode their distro
patch level, since it autoincrements every time the distro maintainer adds
another patch (for example, since I used cygwin, 3.1.17(6) means that I am
using the cygwin package bash-3.1-6, and that cygwin has previously had 5
previous packages of bash-3.1).  Other than that, it is relatively
meaningless in bug reports (your local build 2 may be more up-to-date than
my local build 6, if you started from a more up-to-date patch set when you
first built).

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEWfmR84KuGfSFAYARAsYZAKDBMoajK+YgYhW8jUh76yIBQO5d1ACcD7cp
p9C5jfE5cFyhLfwODQMzi+Y=
=4aMN
-END PGP SIGNATURE-


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


Fwd: Re: Bash-3.1.17 gets lost looking for end of string in certain contexts

2006-05-03 Thread Richard
Have just read the archives... ;) Forwarding to the list accordingly!

--  Forwarded Message  --

Subject: Re: Bash-3.1.17 gets lost looking for end of string in certain 
contexts
Date: Wednesday 03 May 2006 22:36
From: Richard [EMAIL PROTECTED]
To: Eric Blake [EMAIL PROTECTED]

As promised, further to my previous message, hereinafter more data on 
the
subject.

(beware of line wrapping at 72 chars)

xterm history

[EMAIL PROTECTED] rag]$ ldd '/mnt/STG1/bin/bash'
libdl.so.2 = /mnt/STG1/lib/libdl.so.2 (0x4001a000)
libc.so.6 = /mnt/STG1/lib/libc.so.6 (0x4001e000)
/mnt/STG1/lib/ld-linux.so.2 (0x4000)
[EMAIL PROTECTED] rag]$ '/mnt/STG1/bin/bash' --version
GNU bash, version 3.1.17(2)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED] rag]$ strings -a '/mnt/STG1/bin/bash' | grep GCC | head -n 1
GCC: (GNU) 3.4.6
[EMAIL PROTECTED] rag]$ '/mnt/STG1/lib/libc-2.3.6.so'
GNU C Library stable release version 2.3.6, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.6.
Compiled on a Linux 2.6.12 system on 2006-05-01.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
http://www.gnu.org/software/libc/bugs.html.
[EMAIL PROTECTED] rag]$ '/mnt/STG1/bin/bash'
[EMAIL PROTECTED] ~]$ echo $BASH_VERSION
3.1.17(2)-release
[EMAIL PROTECTED] ~]$ status=`echo 'beriberi'| { grep -E -e '().*\1' 
/dev/null
21 ; echo $?; }` || echo OOPS
[EMAIL PROTECTED] ~]$ echo $status
0
[EMAIL PROTECTED] ~]$ cd /mnt/STG1/opt/sources/grep-2.5.1a/tests
[EMAIL PROTECTED] tests]$ GREP=grep /mnt/STG1/bin/bash spencer1.script
spencer1.script: line 602: unexpected EOF while looking for matching `''
spencer1.script: line 608: syntax error: unexpected end of file
[EMAIL PROTECTED] tests]$

/xterm history

As you can see the bare command does not trigger the error; however the
script for some contextual reason does trigger it.

Just curious: why is it that your version displays 6 within parenthesis,
whereas mine displays 2?

At your disposal for any addtional info you may require.

Richard

---


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