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

Terminating ceylon help with less pager leaves terminal in dirty state #53

Open
lucaswerkmeister opened this issue Mar 23, 2015 · 17 comments
Labels
Milestone

Comments

@lucaswerkmeister
Copy link
Member

On Linux, with default pager settings, run ceylon help, then terminate the process with Ctrl+C. This will leave the terminal in a weird state where:

  • less is terminated, but its output still visible
  • your prompt is printed (right after the less prompt ‘:’)
  • the next character will be swallowed (for some meaning of “character” – Esc and Enter have the same effect, while Ctrl+C will re-print the prompt)
  • upon entering that character, the terminal will reset to show the regular output before less was started
  • the terminal is “silent”, characters typed are not echoed – blind-type reset and hit Enter to fix this

I have no idea what’s going on here; I tried to investigate it, but didn’t arrive at any conclusions. Notes:

  • less is supposed to stay open when its input is closed, and ignore Ctrl+C itself. This is useful, for instance, when running git log -Ssearch (or another expensive Git operation) – you’ll terminate git after the first few results are there, then look through those results with less still up.

    • in the above scenario, git actually continues running after terminated – not sure what’s happening here.
  • piping ceylon help into less manually works without problems.

  • this only happens for less, CEYLON_PAGER=more ceylon help works without problems.

  • it happens no matter how much you hide less:

    echo -e "#!/bin/bash\nsleep 1; bash -c 'sleep 1; less'" > pager;
    chmod +x ./pager;
    CEYLON_PAGER=./pager ceylon help

CC ceylon/ceylon-compiler#1506.

@quintesse
Copy link
Member

I'm guessing less doesn't like to be forcefully interrupted. If run by itself in a shell it won't accept CTRL-C but if you use it with the -K option it does exit but probably is able to do proper cleanup which it isn't able to do when run from within the Ceylon command process.

@quintesse
Copy link
Member

I tried simulating that behaviour by doing git checkout --help and then killing the less process, but that actually works okay (it gives a command exited message and nothing more).

@lucaswerkmeister
Copy link
Member Author

If you kill (SIGTERM) the less process, the terminal is still “blind”, but the weird “gobble character and swap out screens” thing doesn’t happen. If you just run less by itself, it works fine.

@lucaswerkmeister
Copy link
Member Author

If you SIGKILL the java process, the “gobble character and swap out screens” happens, but afterwards the terminal is no longer “blind”. Are those two independent effects?

@FroMage FroMage modified the milestone: 1.2 Apr 10, 2015
@quintesse
Copy link
Member

You have any good ideas for this @FroMage ? I've even been looking at preventing ctrl+c or to terminate in a controlled way when a user does ctrl+c but that's actually not very easy to do in Java.

@lucaswerkmeister
Copy link
Member Author

Perhaps we could nohup Java in the startup script?

@FroMage
Copy link
Member

FroMage commented Aug 24, 2015

I don't understand why less on its own traps C-c but not when run from Ceylon.

@quintesse
Copy link
Member

@FroMage Well, what I'm guessing from what I've found googling for problems with Java and ctril+c is that Java probably does it's own handling of that signal which basically comes down to: kill all children and then exit. So it's possible that lessdoes not have a chance to do any cleanup because it gets forcibly killed... things is that I tried to mimic that by trying to kill an active less in all kinds of ways and I couldn't reproduce the problem.

@quintesse
Copy link
Member

@lucaswerkmeister but that would affect all Ceylon applications in all circumstances, that doesn't seem like something we would want.

@gavinking
Copy link
Member

@quintesse @lucaswerkmeister this issue is assigned to 1.2. Please do something to it.

@quintesse
Copy link
Member

What? @FroMage made this and we have to clean up his mess? ;)
But I've tried all kinds of things I could think of and I haven't found a way to prevent this.
So for now I'm all out of options except for hard-coding the use of more

@FroMage
Copy link
Member

FroMage commented Sep 18, 2015

Bah, if we can't fix it, let's just close it.

@quintesse
Copy link
Member

Dunno, people won't get it in general, but when they do it's pretty nasty, it basically means you need to restart your terminal.

@FroMage
Copy link
Member

FroMage commented Sep 18, 2015

reset is a common workaround for every program which does this. Look, let's just close this until someone comes up with a solution.

@quintesse
Copy link
Member

What? Close it to forget about it, is this somehow the new rage? What happened to just assigning it to the next release to see if we can come up with something in the mean time?

And I doubt many people know about reset.

@FroMage
Copy link
Member

FroMage commented Sep 18, 2015

Fine, move it ;) I've known about reset since my first VT100, man, where were you all this time?

@FroMage FroMage added the bug label Sep 18, 2015
@FroMage FroMage modified the milestones: 1.3, 1.2 Sep 18, 2015
@quintesse
Copy link
Member

In the same place where I keep my "export TERM=ansi" information, tucked deep away in the hope one day I'll forget about all that ;)

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

4 participants