Re: bash-3.1-7 BUG

[ericblake at comcast dot net (Eric Blake)]

> At any rate, thanks for narrowing down your application
> to a smaller test case; I'll see what I can find with it.

Here's something interesting in the strace:
   30  518741 [main] bash 2084 readv: readv (255, 0x22C060, 1) blocking, sigcatchers 1
   30  518771 [main] bash 2084 readv: no need to call ready_for_read
   34  518805 [main] bash 2084 fhandler_base::read: read 0 bytes ()
   29  518834 [main] bash 2084 fhandler_base::read: returning 135, text mode
...
   33 1682871 [main] bash 2084 fhandler_base::lseek: lseek (/home/eblake/text/zzz.sh, -103, 1)
   32 1682903 [main] bash 2084 fhandler_base::lseek: setting file pointer to 429
4967295 (high), 4294967193 (low)
   34 1682937 [main] bash 2084 lseek64: 39 = lseek (255, -103, 1)

Seems like a text mode lseek bug (no surprise there, since cgf
predicted that there are still some corner cases).  The file is 142
bytes, but has seven \r\n pairs, so the readv correctly returned 135
characters read.  But the lseek back to the start of the third line
temporarily set the file pointer to -3, then settled on an offset of 39
(39 + 103 gives 142 bytes, as if in binary mode); the offset really
should have been 32 characters in (byte 34 is the start of the third
line, so two \r would be skipped at that point).  I'm still not sure if
it is bash's fault or cygwin's.  But the file definitely was read in
text mode when it resided in a text mount.

-- 
Eric Blake

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/