GNU bug report logs - #6535
24.0.50; grep seems not to work

Previous Next

Full log

Message #56 received at 6535 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Štěpán Němec <stepan.nemec <at> gmail.com>
Cc: 6535 <at> debbugs.gnu.org
Subject: Re: bug#6535: 24.0.50; grep seems not to work
Date: Wed, 30 Jun 2010 13:47:03 +0200

Štěpán Němec skrev 2010-06-29 20.27:
> Jan Djärv<jan.h.d <at> swipnet.se>  writes:
>
>> Štěpán Němec skrev 2010-06-29 13.14:
>>>
>>> Nothing suggests anyone is working on fixing the problem. If you have a
>>> fix, why don't you commit it?
>>
>> I don't have a recepie for repeating the problem turning off ICANON would
>> solve.  It isn't a high priority for me.
>
> I wonder what makes you assume somebody is working on it then.

I did some tests when this come up.  Basically I adopted xterm:s approach with 
buffering.  But this makes send_process asynchronous when the subprocess isn't 
reading.  It may be a too big of a change.
Besides, with the current send_process implementation, it does seem to do the 
right thing, so asynchronous send is perhaps not needed.  As I said, I haven't 
been able to trigger any problem with it, RAW or ICANON.  The only problem is 
if the subprocess doesn't read, Emacs hangs forever.

The code and the documentation is not in sync w.r.t. EOF either.

>
>>> If you don't have a fix *now*, why is the
>>> breakage not reverted for the time being? I didn't even get any reaction
>>> on this question.
>>
>> That you must ask the person who made that checkin.
>
> ...which I did. I posted the URL in this thread already.

He may not read this thread.

>
>>>
>>> I don't expect the trunk to be perfectly usable all the time, but I fail
>>> to see any value in leaving a known and repeatedly reported breakage in
>>> for an extended period of time.
>>>
>>
>> The breakage must have fixed some other problem.  If breakage one is better
>> than breakage two is a matter of opinion, depending which one you see the
>> most.  AFAIK, I haven't seen either.
>
> I can't make much sense of Stefan's commit message. It also doesn't
> mention any related bug it would be supposed to fix.

The code mentions the same problem to the current one (EOF showing up as ^D) 
because the terminal is in raw mode.  The scenario is that Emacs puts the 
terminal in icanon mode and then the subprocess puts it in raw, ^D will be 
seen by the subprocess because Emacs sends EOF as a means to flush output.

But AFAIK, Emacs doesn't send EOF to flush output anymore.

So I wont put in my stuff until Stefan has commented on his.  I don't think 
this is a pressing matter, this is the trunk after all, and people have other 
things to do.  It must be resolved before next release though.

	Jan D.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.