On 8/17/14, 1:47 AM, Linda Walsh wrote:
> ?? Could this be a cygwin bug? It's hard to see why cygwin
> would start using lseek calls when running bash unless bash called
> them... but then tha's not to say something else entirely may be going on as
> this is running on Windows... ;-/
The original poster's speculation is correct. Bash is not allowed to
read more input from stdin than it actually consumes, so commands that
it runs get the intended input. To that end, it tries to detect whether
or not the fd it is using for standard input is seekable: if it is, bash
assumes that it can correctly position the file pointer by seeking
backwards; if it is not, bash reads a character at a time.
Bash uses lseek to the current file position to check this. If the lseek
returns -1/EPIPE, bash assumes the fd is not seekable. If it returns 0,
bash assumes that it can move around freely. Since bash is trying to seek
backwards in the file, stdin is either a regular file or a tty (in which
case bash assumes that reads are newline-delimited by the device driver).
I suspect what happens is that isatty() returns 1 for serial devices, but
reads are not newline-delimited.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
