[Github-comments] [geany/geany] terminal persistence after crash (#2703)

[ruminations]

24 December 2020 2:00 PM

 

First, thanks for the info about geany internals.

 

I've been using geany for years and having multiple execution terminals simultaneously open

is part of my standard workflow.  It came as a complete surprise that yesterday it would not allow

me to do that.  I remembered that the previous day I had been working in geany when the

powerfail happened, so I began playing with the settings until geany started to behave again.

 

I tried various things, like putting in the complete path to the python binary.  What worked was

when I made a mistake and the execute failed with an error.

 

>From my 'geany.conf':

 


[tools]
terminal_cmd=x-terminal-emulator -e "env PYTHONPATH=/usr/local/lib/python2.7/site-packages /bin/sh %c"
browser_cmd=sensible-browser
grep_cmd=grep

 

Which is standard except for the PYTHONPATH adjustment which points geany to my personal library.

I added that after I discovered that the addendum to my '.bashrc':

 


# 20201017 enable using my personal packages
export PYTHONPATH="/usr/local/lib/python2.7/site-packages"

 


was ineffective from within geany, probably because 'sh' symlinks to some simpler shell.  Beyond

that, all configurations are from a standard ubuntu repository installation that was performed a few

days before the bash and geany configuration alterations.

 

I notice now that the build command is the unaltered default:

 

python "%f"

 

and that differs from the 'geany.conf' file, but that should not matter since the build

command becomes the %c in the config file.

 

Running just now a program that has a lengthy test suite, I see that the execute icon changes

from a gear to the circle slash and changes back almost immediately to the gear icon, where

the test suite is still running as I type this, and has now stopped.  I have no difficulty starting

other executions, even before the lengthy test completes, and all terminals remain open until

I explicitly close them, as I expect should happen.

 

That is to say, everything is working fine now, as it was yesterday after I caused the execute

command to throw an error and then restored the default.

 

The reason I mention this is that your paragraph on the icon behavior does not match my

experience, either over the past years or now.  Moreover, if I run the lengthy test suite and

immediately run the same test suite by clicking the immediately restored gear, I get a new

independent terminal instance and the first invocation does *not* terminate, but continues,

as I would expect it to do.  If I need to terminate the process, I can use ^C or simply close

the terminal window, so this experience also does not match your paragraph.

 

Finally looking in the task manager, I see geany is the parent of the terminal and the

terminal is the parent of a shell which is the parent of the lengthy test, as expected. 

If I suspend by closing the laptop in the middle of the lengthy test, and then reopen

the laptop and touch the power button to resume, the situation remains, as expected.

When the program stops, its process disappears, and the shell and the terminal remain

as expected.  When I close the terminal by whatever method, both the shell process

and the terminal process disappear, as expected.

 

In closing, I realize that the issue I reported is one of the most difficult kinds to track

down, and it is not likely to affect many people.  It is, however, real.  I did in fact

spend an hour of my time yesterday trying to resolve it.  The workaround I discovered

is effective, and given the rarity of  occurence, I certainly don't expect any concerted

effort to resolve it.  It should, however, remain in the back of your mind, especially

when you happen to be working on the geany initialization code, or perhaps gui

interactions with the os window manager.

 

I should point out that I am using Bodhi linux (5.1.0) which uses a variant of the

enlightenment libraries.  These are peculiar libraries, and you either love them or

hate them, and they do have some quirks.  The problem may be some bizarre

interaction between your gui libraries (presumably still gtk, for I chose geany

specifically because it uses gtk) and the enlightenment libraries, even if there

really is no temporary state storage in geany.

 

Sincerely

 

John_Hull

John_Hull at mail.com


 
 

Sent: Wednesday, December 23, 2020 at 5:56 PM
From: "elextr" <notifications at github.com>
To: "geany/geany" <geany at noreply.github.com>
Cc: "ruminations" <John_Hull at mail.com>, "Author" <author at noreply.github.com>
Subject: Re: [geany/geany] terminal persistence after crash (#2703)


 

If the Geany execute command item is activated while a command is running it terminates the command, this allows programs that get into an infinite loop to be terminated. When running in a terminal Geany does not know the process ID of the program, only of the terminal, so that is what is terminated, and hopefully it will terminate the program. Similarly as it does not know the program process id there is no way Geany can find out if the program has finished, only if the terminal has finished, so the execute action remains as "stop" until the terminal closes. So this part is working as intended.

Geany does not store any execute state when it closes because it no longer owns the terminal process when its restarted (if that process still existed) so there is no point in it doing so. I suspect that if the execute icon stays at stop then your laptop is not shutting down, it is hibernating or suspending, so Geany is restored in its previous state, but I have no idea if the terminal process termination is correctly delivered in that case, possibly not, but its not a scenario Geany has been designed to cope with, YMMV.

If you want to have multiple terminals open the command Geany runs (from Preferences->Tools->Terminal) must complete. I havn't tried it, but you could try modifying that preference to run the terminal in a shell and detaching it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2703#issuecomment-751124994
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20201224/dddd8664/attachment-0001.htm>