bugGNU nano - Bugs: bug #44907, opening a file that waits for...


bug #44907: opening a file that waits for input hangs

Submitted by:  Sworddragon <sworddragon>
Submitted on:  Thu 23 Apr 2015 01:48:08 PM UTC  
Severity:  2 - Minor Status:  None
Assigned to:  None Open/Closed:  Open

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 26 Feb 2018 09:35:58 PM UTC, comment #14:

I debugged it and found when reading /proc/ksmg, the ^C causes this loop in "read_file" to exit:

i.e. getc(f) returns an EOF. But this doesn't happen when reading huge (normal) files.

I modified the patch to stop the reading of a huge file as well, in case you're interested (attached v3).

(file #43402)

Martin van Zijl <martinvanzijl>
Wed 21 Feb 2018 11:36:25 AM UTC, comment #13:

Thanks. That patch works. But... I'm surprised that ^C doesn't stop the reading when nano is reading in a huge file. How does that work?

Benno Schulenberg <bens>
Project Administrator
Mon 19 Feb 2018 09:50:24 PM UTC, comment #12:

I used an old git version. I just tried with the latest git and made some updates. It seems to be working now (updated version attached).

(file #43365)

Martin van Zijl <martinvanzijl>
Fri 16 Feb 2018 11:27:22 AM UTC, comment #11:

I run Xubuntu 17.10. But I applied your patch against nano git, whereas you made the patch against a specific version. What version of nano did you patch?

Benno Schulenberg <bens>
Project Administrator
Thu 15 Feb 2018 08:18:53 PM UTC, comment #10:

Thanks, that makes sense.

With the patch applied, the normal ^C still works for me on Ubuntu. What O/S did you test it on?

Martin van Zijl <martinvanzijl>
Tue 13 Feb 2018 07:00:47 PM UTC, comment #9:

Thanks for the patch. (I've updated it for current git, where the whitespace has changed. See attached.)

However, with the patch applied, the normal ^C (Cursor position, or Cancel) does not work anymore. The patch will have to restore the handler that was set before the reading started.

(I'm probably not going to apply the patch, as I think it is too small an issue to bother about. If it were a two-line fix, okay, but a thirty-line patch...)

(file #43275)

Benno Schulenberg <bens>
Project Administrator
Sun 11 Feb 2018 11:08:53 PM UTC, comment #8:

I've attached a patch which works for me (on Ubuntu 14.04).

Now if I do

./src/nano /proc/kmsg

then ^C cancels the reading and goes into normal editing mode.

(file #43256)

Martin van Zijl <martinvanzijl>
Sat 02 Jul 2016 04:41:03 PM UTC, comment #7:

Emacs one can stop by typing first ^G and then ^X^C. Experienced emacs users will know this, but for me... brrr. Gedit is even nicer: it will start up and then show an empty tab with a turning busy indicator. One can simply close the tab with ^W or quit with ^Q.

On the other hand, Geany and joe and dex will just hang on the command line -- which is a very weak indication of being busy reading the file, but it's better than mped who will startup and then hang in a blank window.

Meanwhile, nano has gotten a little better: when not using file locking, it will display "[ Reading File ]" when opening an endless file (a file without an EOF). So at least you know nano has started and is trying to read in stuff.

What we probably should do is: if a thousand reads (or a whole second of reads) have produced zero bytes, look at the keyboard for a ^C.

Benno Schulenberg <bens>
Project Administrator
Sun 26 Apr 2015 01:08:56 PM UTC, comment #6:

Correction: what I meant, of course, was: 'nano /proc/kmsg'.

Benno Schulenberg <bens>
Project Administrator
Sat 25 Apr 2015 05:52:53 PM UTC, comment #5:

Okay, yes, 'nano /proc/kmesg' hangs. But so does opening that file with 'vim' or 'emacs -nw'. Vim is somewhat better, because it initializes part of the screen, so you kind of know it is stuck on the file listed on the bottom line. Emacs is totally frustrating -- it seems to have initialized, but doesn't react to any keyboard input.

Pico is nice: it initializes the screen and then hangs saying "[Reading File]". Very nice. It is completely clear what is happening. Nano should do something like that. And then... it would be nice if it allowed the reading to be cancelled with ^C.

Benno Schulenberg <bens>
Project Administrator
Fri 24 Apr 2015 07:07:46 PM UTC, comment #4:

> I don't have scite. Please give me a simpler recipe.

Opening /proc/kmsg with nano as root causes this behavior on my system too.

> And that file, by the way, doesn't look like something you should want to be editing.

Yes, but this can happen by accident. Normally I would either expect that nano refuses to open such files (or opens an empty file) or that the main controls would not hang (for example by using an extra thread on handling documents) so that nano can be still closed without terminating it.

> But if you do, do other editors, like vim or emacs or gedit, have no problems?

I have tested several applications on my system that can open files (not only text editors) and the most of them are handling this fine (either by not opening the file/giving an error message or by reading/waiting for it in a non-blocking way so that the application does not hang).

Sworddragon <sworddragon>
Fri 24 Apr 2015 07:28:48 AM UTC, comment #3:

I don't have scite. Please give me a simpler recipe.

And that file, by the way, doesn't look like something you should want to be editing. But if you do, do other editors, like vim or emacs or gedit, have no problems?

Benno Schulenberg <bens>
Project Administrator
Thu 23 Apr 2015 10:20:58 PM UTC, comment #2:

I have tested this with the file /tmp/SciTE._pid_.in that the text editor SciTE creates while it is running.

Sworddragon <sworddragon>
Thu 23 Apr 2015 06:40:03 PM UTC, comment #1:

Cannot reproduce. I've tried with 'cat - >waiting', typing something, and then running 'nano waiting' in another terminal. It opens fine, and closes fine.

Can you give a simple, reproducing recipe?

Benno Schulenberg <bens>
Project Administrator
Thu 23 Apr 2015 01:48:08 PM UTC, original submission:

I'm using nano 2.2.6 and if I'm opening a file that waits for input nano hangs. In this state it is also not possible to close nano anymore without terminating it.

Sworddragon <sworddragon>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #43256:  fix-for-issue-44907.patch added by martinvanzijl (2KiB - text/x-patch - Proposed patch.)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by martinvanzijl (Updated the item)
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by sworddragon (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-26 martinvanzijl Attached File- => Added allow-to-interrupt-reading-v3-huge-files-also.patch, #43402
    2018-02-19 martinvanzijl Attached File- => Added allow-to-interrupt-reading-v2.patch, #43365
    2018-02-16 bens Severity3 - Normal => 2 - Minor
    2018-02-13 bens Attached File- => Added allow-to-interrupt-reading.patch, #43275
    2018-02-11 martinvanzijl Attached File- => Added fix-for-issue-44907.patch, #43256
    2015-04-25 bens SummaryOpening a file that waits for input does hang => opening a file that waits for input hangs

    Back to the top

    Powered by Savane 3.3