Opened 11 years ago
Closed 10 years ago
#2284 closed enhancement (fixed)
Keep pressing Ctrl+C in command line
| Reported by: | hcho | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.0.0 |
| Component: | Startup | Version: | svn-trunk |
| Keywords: | prompt | Cc: | |
| CPU: | x86-64 | Platform: | All |
Description
Since we changed the init script to python, I've been getting the following message whenever I keep pressing Ctrl+C in command line:
^CTraceback (most recent call last):
File "/home/grass/trunk/dist.x86_64-unknown-linux-gnu/etc/prompt.py", line 3, in <module>
import os
KeyboardInterrupt
It doesn't cause any real problems, but it doesn't look nice. Also, the overall responsiveness of the prompt became much slower than when we were in init.sh.
Can we fix this? Or can we opt to use the old init.sh, which I think is gone now?
I believe the main motivation of this migration to python was to support MS-Windows, but it somehow hurts performance on Unix.
Change History (6)
comment:1 by , 11 years ago
follow-up: 4 comment:3 by , 11 years ago
| Platform: | Linux → All |
|---|---|
| Resolution: | fixed |
| Status: | closed → reopened |
comment:4 by , 11 years ago
Replying to neteler:
In case this also works for Windows, what about backporting to relbr7? Has it been tested on Windows?
I can't think of any reason why it wouldn't. It should only be used for bash (even in the script tries to use bash_startup() for something other than bash, the code in question is written to .bashrc, which shouldn't be read by anything which isn't actually bash), and Windows versions of bash go to some lengths to maintain compatibility (they wouldn't be of much use otherwise).
comment:5 by , 10 years ago
| Keywords: | prompt added |
|---|
comment:6 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Seems to work ok, closing.
Replying to hcho:
There's no reason to revert to init.sh, but we could replace prompt.py with the bash version (prompt.sh) from 6.x. The prompt script is only used if you're using bash as your shell, so portability isn't an issue.
You can disable the fancy prompt with "unset PROMPT_COMMAND".
The error could probably be avoided by wrapping the entire prompt.py script in a try/except block, but that wouldn't help with performance. Ignoring the signal wouldn't work reliably, because you'd have to import the signal module first, and any signal raised during that time would still result in the KeyboardInterrupt exception.