Chet Ramey wrote:
> Daniel Musgrave wrote:
>> I have found a seeming inconsistency with the behavior of the read
>> builtin of bash (3.2.0(1)-release, also tested in 3.00.15(1)-release).
>> I'm working on a Centos 4.4 system (RedHat derivative). Let me describe
>> the conditions that cause the bu
Daniel Musgrave wrote:
> I have found a seeming inconsistency with the behavior of the read
> builtin of bash (3.2.0(1)-release, also tested in 3.00.15(1)-release).
> I'm working on a Centos 4.4 system (RedHat derivative). Let me describe
> the conditions that cause the bug in as much detail as I
Daniel Musgrave <[EMAIL PROTECTED]> writes:
> If the line matches the above conditions and is echoed without being
> quoted ($var, not "$var"), the result is the single character 'w'.
Read the manual about Filename Expansion.
> Similarly, 'echo [w]' produces the expected output of '[w]',
Try th
I have found a seeming inconsistency with the behavior of the read
builtin of bash (3.2.0(1)-release, also tested in 3.00.15(1)-release).
I'm working on a Centos 4.4 system (RedHat derivative). Let me describe
the conditions that cause the bug in as much detail as I have discovered
thus far.
If
Configuration Information [Automatically generated, do not change]:
Machine: sparc64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='sparc64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/pkg/bash/sha
Stuart Shelton wrote:
The following problems exist, at the very least, in bash 3.1.16, 3.1.17,
and 3.2.1 - I assume it affects the all bash-3.x releases.
If bash is built with the SGI MIPSpro compilers then, now matter what
other CFLAGS are in affect, the test suite fails in many ways (and one
