[GRASS-dev] [GRASS GIS] #2284: Keep pressing Ctrl+C in command line

[Glynn Clements]

Huidae Cho wrote:

> Ok, Let me understand it. So the keyboard interrupted exception is coming
> from prompt.py, not from grass.py.

Yes; from the original bug report:

> ^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


> If I replace prompt.py with prompt.sh,
> I'm out of python completely and not facing performance hit either?

I haven't really looked into the performance hit, but I would expect
Python to have a higher startup overhead than bash.

Both scripts do essentially the same thing, i.e. they use g.gisenv to
determine the mapset directory, check for the existence of raster
and/or volume masks, then print a message if either or both of those
exist.

If PROMPT_COMMAND is set, the command is run immediately before bash
prints a primary prompt (when it's time for a new command, as opposed
to a secondary prompt which is printed at the start of each
continuation line in a multi-line command).

I suspect that most of the overhead is from Python starting up and
importing modules. It imports os, sys and gettext directly, as well as
grass.script.core, which in turn imports os, sys, types, re, atexit,
subprocess, shutil, locale, codecs, and gettext.

This overhead is likely to be insignificant for a "real" script which
does non-trivial processing, but for a trivial script which is run for
each prompt, it may be an issue.

OTOH, the Python version only executes g.gisenv once, whereas the
shell version executes it 3 times (once for each variable).

> I thought as long as grass.py launches bash with whatever PROMPT_COMMAND
> either being prompt.py or prompt.sh, I'm inside a python process and cannot
> avoid keyboard interuption exceptions and slow performance.

The process running the grass.py script still exists as the shell's
parent process, but it's just in a blocking wait for the shell to
exit.

-- 
Glynn Clements <glynn at gclements.plus.com>