Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

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

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

Comments

@CeylonMigrationBot
Copy link

[@lucaswerkmeister] 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 #1506.

[Migrated from ceylon/ceylon-common#53]

@CeylonMigrationBot
Copy link
Author

[@quintesse] 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.

@CeylonMigrationBot
Copy link
Author

[@quintesse] 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).

@CeylonMigrationBot
Copy link
Author

[@lucaswerkmeister] 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.

@CeylonMigrationBot
Copy link
Author

[@lucaswerkmeister] 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?

@CeylonMigrationBot
Copy link
Author

[@quintesse] 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.

@CeylonMigrationBot
Copy link
Author

[@lucaswerkmeister] Perhaps we could nohup Java in the startup script?

@CeylonMigrationBot
Copy link
Author

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

@CeylonMigrationBot
Copy link
Author

[@quintesse] @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.

@CeylonMigrationBot
Copy link
Author

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

@CeylonMigrationBot
Copy link
Author

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

@CeylonMigrationBot
Copy link
Author

[@quintesse] 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

@CeylonMigrationBot
Copy link
Author

[@FroMage] Bah, if we can't fix it, let's just close it.

@CeylonMigrationBot
Copy link
Author

[@quintesse] 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.

@CeylonMigrationBot
Copy link
Author

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

@CeylonMigrationBot
Copy link
Author

[@quintesse] 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.

@CeylonMigrationBot
Copy link
Author

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

@CeylonMigrationBot
Copy link
Author

[@quintesse] 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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant