On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote: >On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote: >> BTW: >> I started up filemon to watch what was going on from it's standpoint, and it >> shows a huge number of READs on libtool, all SUCCESS, but the offset is >> always >> 1 higher than previous, with a length of 1. Like it's literally reading the >> file >> 1 byte at a time, then incrementing the offset - until it has fully been >> read. >> >> -cl > >So right smack dab in the middle of _evalfile() under bash-3.1: > >#if defined (__CYGWIN__) && defined (O_TEXT) > setmode (fd, O_TEXT); >#endif > >Also in read_comsub(): > >#ifdef __CYGWIN__ > setmode (fd, O_TEXT); /* we don't want CR/LF, we want Unix-style */ >#endif > >And most importantly in open_shell_script(): > > /* Open the script. But try to move the file descriptor to a randomly > large one, in the hopes that any descriptors used by the script will > not match with ours. */ > fd = move_to_high_fd (fd, 0, -1); > >#if defined (__CYGWIN__) && defined (O_TEXT) > setmode (fd, O_TEXT); >#endif > >The high fd part jives with the '255' seen in the readv() strace output as >well. > >This post from 2000 looks related: > >http://ecos.sourceware.org/ml/cygwin/2000-10/msg00213.html > >In regards to setting the fd to textmode as a way of stripping CRs. >Only problem is that it's making 213,110 syscalls for a 213k libtool >script. That cannot be an efficient way to remove CRs from input.
Opening a file with O_TEXT should not, AFAIK, cause a bunch of one-byte reads. A simple test case (tm) seems to confirm that. cgf -- 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/
