Opened 6 years ago

Closed 5 years ago

#2284 closed enhancement (fixed)

Keep pressing Ctrl+C in command line

Reported by: hcho Owned by: grass-dev@…
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 in reply to:  description Changed 6 years ago by glynn

Replying to hcho:

Can we fix this? Or can we opt to use the old init.sh, which I think is gone now?

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.

comment:2 Changed 6 years ago by hcho

Resolution: fixed
Status: newclosed

Fixed in r60216

comment:3 in reply to:  2 ; Changed 6 years ago by neteler

Platform: LinuxAll
Resolution: fixed
Status: closedreopened

Replying to hcho:

Fixed in r60216 resolution set to fixed

In case this also works for Windows, what about backporting to relbr7? Has it been tested on Windows?

1457	elif sh in ['bash', 'msh', 'cygwin']:
1458	    bash_startup()

comment:4 in reply to:  3 Changed 6 years ago by glynn

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 Changed 6 years ago by neteler

Keywords: prompt added

I have backported r60216 + r60222 + r60223 to relbr7 in r60735, hopefully without side-effects. Please test on Windows + MacOSX.

comment:6 Changed 5 years ago by neteler

Resolution: fixed
Status: reopenedclosed

Seems to work ok, closing.

Note: See TracTickets for help on using tickets.