Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocks IO after using ncmpc #822

Closed
greenfork opened this issue May 9, 2019 · 5 comments
Closed

Blocks IO after using ncmpc #822

greenfork opened this issue May 9, 2019 · 5 comments
Labels

Comments

@greenfork
Copy link

After I use ncmpc (music daemon for mpd) it launches curses client, I quit it and the IO is blocked, e.g. cat says

/usr/bin/cat: -: Resource temporarily unavailable
Exception: cat exited with 1
[tty], line 1: cat

I also tried using another curses based app cfdisk. If I use it after the session where I used ncmpc it has no effect. But if I use it before ncmpc then no problem occurs even after I use ncmpc.

I also tried nudoku, sudoku game on curses. Which produces no problem by itself but has no effect on ncmpc.

OS: VoidLinux
elvish: HEAD
ncmpc:

ncmpc version: 0.34
build options: multibyte wide locale iconv nls colors getmouse artist-screen help-screen search-screen song-screen key-screen outputs-screen
@xiaq
Copy link
Member

xiaq commented Jul 20, 2019

I don't have a Linux box to debug this right now, but

  • Does calling reset fix the problem?
  • What is output of stty before and after running ncmpc?

@greenfork
Copy link
Author

stty before and after outputs same string:

speed 38400 baud; line = 0;
-brkint -imaxbel iutf8

reset does not fix the problem.

@hanche
Copy link
Contributor

hanche commented Aug 11, 2019

I think this is likely related, perhaps even the very same same issue, as #588.

@xiaq
Copy link
Member

xiaq commented Aug 11, 2019

I have a Linux box to debug this now. I suspect that ncmpc uses nonblocking IO itself and is not putting the terminal back in blocking mode correctly.

@hanche
Copy link
Contributor

hanche commented Aug 11, 2019

That's my guess too. But as I said in a comment on my old issue referenced above, elvish ought to be able to recover from this. That probably means explicitly putting the terminal back in blocking mode at some appropriate point, such as after a command has been run.

xiaq added a commit that referenced this issue Aug 11, 2019
@xiaq xiaq closed this as completed Aug 11, 2019
xiaq added a commit that referenced this issue Aug 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants