local unset IFS behaves as if local IFS is set but empty

2005-08-20 Thread Harald van Dijk

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/tmp/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib   -g -O2
uname output: Linux boostbox 2.6.13-rc6 #1 Tue Aug 9 21:45:47 CEST 2005 i686 
AMD Duron(tm) Processor AuthenticAMD GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.0
Patch Level: 16
Release Status: release

Description:
If I localise IFS in a function, and then unset it, it gets unset. However, if I 
then use an unquoted variable, it doesn't actually get split. This is what I expect from 
IFS="", not from unset IFS.

Repeat-By:
var="a   b   c"
f() {
local IFS
unset IFS
echo ${IFS+set} # shows nothing, meaning IFS is really unset
echo ${var} # shows "a   b   c" rather than "a b c" (without 
quotes)
}
f


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


user not informed of inputrc errors

2005-08-20 Thread Dan Jacobson
In the man page
   history-preserve-point
needs its default value listed:
   history-preserve-point (Off)

P.S., let's say one just wants to turn it on for a couple of commands.
The man page's Readline Initialization section makes it seem that the
only chance of setting history-preserve-point is by putting it in an
inputrc file, and the only time the inputrc is read is at the birth of
a new shell. Nothing like set -o available. Hope it isn't true.

P.P.S., Here,
} Except where noted, readline variables can take the values On
} or Off. The variables and their default values are:
Mention that lowercase 'on' and 'off' are OK too.

PPPS, also mention the command to dump all the current readline
settings to the screen. All we see is how to set them, no command for
how to see their current values.

What's real bad is that the user is not told of any problems
encountered in reading inputrc.

The user could put
   set history-preserve-point on #cool!
there, and never be informed that that line was considered an error.
Yes the man page says comments must be on the beginning of lines.

The user could even put
   z
in inputrc, with no error message that something was wrong.


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