On Thu, Sep 14, 2006 at 12:58:36PM -0400, Volker Quetschke wrote:
> > +#ifdef __CYGWIN__
> > + /* lseek'ing on text files is problematic; lseek reports the true
> > + file offset, but read collapses \r\n and returns a character
> > + count. We cannot reliably seek backwards if nr is small
> I suspect that the "Well, they can just install Linux (floppies, CDs,
> DVDs) if they feel like it" observation has been made several times a
> year for the last ten years. It's obviously not a very powerful
> argument since Cygwin is still here and you can't really assert that the
> only reason
On Wed, Sep 13, 2006 at 08:19:02PM -0400, Christopher Faylor wrote:
> As long as you have Corinna or myself in charge we are going to stick
> with the whole "Linux on Windows" thing. If bash doesn't like \r\n line
> endings on Linux, if we purposely recommend against using text mode
> files, and i
Carlo Florendo wrote:
Larry Hall (Cygwin) wrote:
I think this is getting a little off-track. Another option just
means another
area for people who don't understand what's going on to trip and fall
and then
come and bug the list as a result. IMO, there's already such an
option, even
without
Larry Hall (Cygwin) wrote:
I think this is getting a little off-track. Another option just means
another
area for people who don't understand what's going on to trip and fall
and then
come and bug the list as a result. IMO, there's already such an
option, even
without changing bash. It's c
Volker Quetschke scytek.de> writes:
> >
> (snip)
> > +#ifdef __CYGWIN__
> > + /* lseek'ing on text files is problematic; lseek reports the true
> > + file offset, but read collapses \r\n and returns a character
> > + count. We cannot reliably seek backwards if nr is smaller than
> > +
Dave Korn wrote:
> On 14 September 2006 17:59, Volker Quetschke wrote:
>
>> Hi!
>
>> (snip)
>>> +#ifdef __CYGWIN__
>>> + /* lseek'ing on text files is problematic; lseek reports the true
>>> + file offset, but read collapses \r\n and returns a character
>>> + count. We cannot reliably s
On 14 September 2006 17:59, Volker Quetschke wrote:
> Hi!
> (snip)
>> +#ifdef __CYGWIN__
>> + /* lseek'ing on text files is problematic; lseek reports the true
>> + file offset, but read collapses \r\n and returns a character
>> + count. We cannot reliably seek backwards if nr is smalle
Hi!
Eric Blake wrote:
> According to Christopher Faylor on 9/13/2006 8:07 PM:
>>> I doubt that Eric will want to deal with the fallout of having bash not
>>> understand \r\n line endings but, if he does, it would be his decision
>>> and, again, I would support it 100%. I am very eager to see thin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 9/13/2006 8:07 PM:
>
> I doubt that Eric will want to deal with the fallout of having bash not
> understand \r\n line endings but, if he does, it would be his decision
> and, again, I would support it 100%. I am ver
On Wed, Sep 13, 2006 at 06:09:03PM -0700, Volker Quetschke wrote:
>Christopher Faylor wrote:
>> On Wed, Sep 13, 2006 at 04:46:28PM -0700, Volker Quetschke wrote:
>(snip)
>>
>>Do I have to make the observation again that whether this is the case
>>or not, it is not a primary goal of the Cygwin proj
Christopher Faylor wrote:
> On Wed, Sep 13, 2006 at 04:46:28PM -0700, Volker Quetschke wrote:
(snip)
>
> Do I have to make the observation again that whether this is the case or
> not, it is not a primary goal of the Cygwin project to support these
> people?
Yes. Did it ever cross your mind that
David Rothenberger wrote:
On 9/13/2006 4:46 PM, Volker Quetschke wrote:
mwoehlke wrote:
Eric Blake wrote:
mwoehlke tibco.com> writes:
(snip)
... If the file starts life binary mode (ie. was on a binary
mount), skip the check for \r in the scan (under the assumption that
on a binary mount, \
On Wed, Sep 13, 2006 at 04:46:28PM -0700, Volker Quetschke wrote:
>mwoehlke wrote:
>>Eric Blake wrote:
>>>mwoehlke tibco.com> writes:
>(snip)
>>>... If the scan in binary mode succeeds, then leave the file in binary
>>>mode, assuming that the file is unix format even though it is on a text
>>>mou
On 9/13/2006 4:46 PM, Volker Quetschke wrote:
mwoehlke wrote:
Eric Blake wrote:
mwoehlke tibco.com> writes:
(snip)
... If the file starts life binary mode (ie. was on a binary
mount), skip the check for \r in the scan (under the assumption that
on a binary mount, \r is intentional and not a
Hi,
mwoehlke wrote:
> Eric Blake wrote:
>> mwoehlke tibco.com> writes:
(snip)
>> ... If the scan in binary mode
>> succeeds, then leave the file in binary mode, assuming that the file
>> is unix format even though it is on a text mount, and that lseeks will
>> work. If the file starts life bina
Eric Blake wrote:
mwoehlke tibco.com> writes:
Would it be possible to do this dynamically (instead of keying off of
mounts, etc.): if the first line of the file read by bash has a \r\n,
use text-mode (1-char-at-a-time) semantics, else use binary semantics
(lseek)?
I hate to say this, but...
mwoehlke tibco.com> writes:
> > Would it be possible to do this dynamically (instead of keying off of
> > mounts, etc.): if the first line of the file read by bash has a \r\n,
> > use text-mode (1-char-at-a-time) semantics, else use binary semantics
> > (lseek)?
>
> I hate to say this, but...
Shankar Unni wrote:
Eric Blake wrote:
But I intend that on binary files, \r\n line endings will treat the \r
as part of the line, so at least binary mounts won't suffer from the
speed impact of treating a file as unseekable the way bash 3.1-6 does.
Would it be possible to do this dynamically
Eric Blake wrote:
But I intend that on binary files, \r\n
line endings will treat the \r as part of the line, so at least binary mounts
won't suffer from the speed impact of treating a file as unseekable the way
bash 3.1-6 does.
Would it be possible to do this dynamically (instead of keying
Christopher Faylor cygwin.com> writes:
> Is bash assuming that it can read N characters and then subtract M
> characters from the current position to get back to the beginning of a
> line? If so, hmm. I guess this explains why it was reading a byte at a
> time before. It must be counting chara
On Wed, Sep 13, 2006 at 04:38:33AM +, Eric Blake wrote:
>> 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
> 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
> I have extracted very short script which fails by bash-3.1-7,
> while runs successfully 3.1-6 ofcorse.
>
> While the attached script zzz.sh has \r\n style end of line format,
> it shoud run normally since accessed through "text mount" point.
Does it work if you convert it to \n line endings, us
24 matches
Mail list logo
