On Mon, Jan 26, 2009 at 07:13:32AM +0100, Jan Schampera wrote:
> Hi.
>
> In comp.unix.shell [1] somebody wondered about
> IFS=: read a b <<< a:b; echo "'$a' '$b'"
> ending up in
> 'a b' ''
>
> Korn and Z seem to behave different. I see that across all my available
> Bash versions. I remember the colon to be special in some way (was it
> hostnames in a file path?), but I don't know.
>
> If this is intended behaviour, can you tell me why (it's gone with
> quoting/escaping, of course)?
[...]
That would be a bug. Looking at the code, it takes a different
path for colon just because of the fact that in assignment,
tilde expansion is performed after a colon (as in
PATH=...:~/bin), if : happens to also be an IFS character, it is
therefore not internally /quoted/ at some stage of the
processing and then there's splitting involved later on. (that's
my interpretation after a quick look). There's the same problem
with ~ and = at least:
$ bash -c 'IFS="~"; read a b <<< a~q; echo $a'
a q
The fix might be something like:
--- bash-4.0-rc1/subst.c 2009-01-08 12:53:53.000000000 +0000
+++ bash-4.0-rc1/subst.c.new 2009-01-27 06:26:29.000000000 +0000
@@ -7738,6 +7738,7 @@ add_twochars:
/* break; */
default:
+ add_character:
/* This is the fix for " $@ " */
if ((quoted & (Q_HERE_DOCUMENT|Q_DOUBLE_QUOTES)) || (isexp == 0 &&
isifs (c)))
{
@@ -7770,7 +7771,6 @@ add_twochars:
SADD_MBCHAR (temp, string, sindex, string_size);
- add_character:
RESIZE_MALLOCED_BUFFER (istring, istring_index, 1, istring_size,
DEFAULT_ARRAY_SIZE);
istring[istring_index++] = c;
Though I couldn't tell for sure if that's enough or wouldn't
break things.
--
Stéphane
