read -q broken on OSX / BSD?

read -q broken on OSX / BSD?

[Yaniv Aknin]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

Hi,

I'm running % read -q, and then typing a single character which isn't y, Y
 or n. However, the value set in $REPLY isn't n, it is the character I
typed. The documentation<http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html>
 for read -q explicitly says I should expect 'n' if the typed character
wasn't 'y' or 'Y'.

This behavior reproduces on OSX 10.7 using zsh 4.3.11 (default) and 5.0.0
(Homebrew), but not on Linux (Ubuntu 12.04, zsh 4.3.10) - on Linux, the
value in $READ is n, as expected. A kind Internet guy
observed<http://stackoverflow.com/questions/14141933/zsh-read-q-broken-on-osx>the
broken behaviour on zsh
5.0.2 (i386-portbld-freebsd9.1).

Also, I've tried running under zsh -f, same results (i.e., I don't think
it's in my init scripts).

I believe this is a bug, so I thought it best to bring it here.

Thanks for a great shell,

 - Yaniv

Re: read -q broken on OSX / BSD?

[Bart Schaefer]

On Jan 6, 11:06am, Yaniv Aknin wrote:
} Subject: read -q broken on OSX / BSD?
}
} I'm running % read -q, and then typing a single character which
} isn't y, Y or n. However, the value set in $REPLY isn't n, it is the
} character I typed.

This is apparently version-dependent rather than platform-dependent.
It got changed by workers/27188 back in July 2009, but nobody noticed,
which pretty much tells you that read -q was mainly being used for its
exit status and not for what it returned.

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.268
diff -u -r1.268 builtin.c
--- Src/builtin.c	8 Nov 2012 16:50:42 -0000	1.268
+++ Src/builtin.c	6 Jan 2013 18:40:37 -0000
@@ -5490,6 +5490,9 @@
 		eof = 2;
 	    else
 		eof = (bptr - buf != 1 || (buf[0] != 'y' && buf[0] != 'Y'));
+	    buf[0] = eof ? 'n' : 'y';
+	    buf[1] = 0;
+	    bptr = buf+2;
 	}
 	if (OPT_ISSET(ops,'e') || OPT_ISSET(ops,'E'))
 	    fwrite(buf, bptr - buf, 1, stdout);



-- 
Barton E. Schaefer

Re: read -q broken on OSX / BSD?

[Peter Stephenson]

On Sun, 6 Jan 2013 11:06:05 +0200
Yaniv Aknin <yaniv@aknin.name> wrote:
> I'm running % read -q, and then typing a single character which isn't y, Y
>  or n. However, the value set in $REPLY isn't n, it is the character I
> typed. The documentation for read -q explicitly says I should expect
> 'n' if the typed character wasn't 'y' or 'Y'.

That does seem to have gone missing.

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.268
diff -p -u -r1.268 builtin.c
--- Src/builtin.c	8 Nov 2012 16:50:42 -0000	1.268
+++ Src/builtin.c	6 Jan 2013 18:46:21 -0000
@@ -5490,6 +5490,12 @@ bin_read(char *name, char **args, Option
 		eof = 2;
 	    else
 		eof = (bptr - buf != 1 || (buf[0] != 'y' && buf[0] != 'Y'));
+	    if (eof) {
+		*buf = 'n';
+	    } else {
+		*buf = 'y';
+	    }
+	    bptr = buf + 1;
 	}
 	if (OPT_ISSET(ops,'e') || OPT_ISSET(ops,'E'))
 	    fwrite(buf, bptr - buf, 1, stdout);

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: read -q broken on OSX / BSD?

[Bart Schaefer]

On Jan 6,  6:47pm, Peter Stephenson wrote:
}
} That does seem to have gone missing.

So we have competing patches again.  I've already committed mine, but
it seems I may have gotten the value of bptr wrong?

Re: read -q broken on OSX / BSD?

[Peter Stephenson]

On Sun, 06 Jan 2013 14:13:07 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jan 6,  6:47pm, Peter Stephenson wrote:
> }
> } That does seem to have gone missing.
> 
> So we have competing patches again.  I've already committed mine, but
> it seems I may have gotten the value of bptr wrong?

Yes, I don't think it should include the null.

Now I look, if we're going to tinker like that, the zfree(buf, bptr -
buf + 1) becomes a bit dodgy, too.

-- 
Peter Stephenson <p.stephenson@samsung.com>       Consultant, Software
Tel: +44 (0)1223 434724              Samsung Cambridge Solution Centre
St John's House, St John's Innovation Park,
Cowley Road, Cambridge, CB4 0ZT, UK

Re: read -q broken on OSX / BSD?

[Bart Schaefer]

On Jan 7,  9:47am, Peter Stephenson wrote:
}
} Now I look, if we're going to tinker like that, the zfree(buf, bptr -
} buf + 1) becomes a bit dodgy, too.

Is there really any case where the size passed to zfree matters?  IIRC
in the heap code we're passing only the size of the header structure,
not the size of the actual allocated block.

Re: read -q broken on OSX / BSD?

[Peter Stephenson]

On Mon, 07 Jan 2013 08:04:16 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jan 7,  9:47am, Peter Stephenson wrote:
> }
> } Now I look, if we're going to tinker like that, the zfree(buf, bptr -
> } buf + 1) becomes a bit dodgy, too.
> 
> Is there really any case where the size passed to zfree matters?  IIRC
> in the heap code we're passing only the size of the header structure,
> not the size of the actual allocated block.

It's an optimisation for the internal allocation mechanism; it starts
searching at the size you give, but if it doesn't find it it starts
again from size zero.  So the worst case is if you give a size that's
too large, otherwise it's at least as good as specifying the size as
zero, which is equivalent to not specifying it.

How much time this saves is now lost in the midst of time.

Anyway, it doesn't look like it needs changing in this case.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/