add menu option to rerun -e command about roxterm

[realh]

I see there is a Profile setting to automatically restart the command upon exit, but if I'm not mistaken, that isn't exposed as a menu option.

I'll try creating a custom profile with no command specified, but with that preference set, and use the "-p PROFILE" command line option to specify that profile with the -e option.

Original comment by: tmetro

[realh]

You can use Profiles to configure the command to run and/or get it to run the command repeatedly (I think the latter reruns the -e command rather than what's configured by the profile, but I can't remember for sure without checking the code). Is that any good? I think the next best thing I could do would be to add an option to open a dialog to let the user choose what to do after the command terminates.

Original comment by: realh

[realh]

At first I was thinking only in terms of what happens if the command exits when it fails, but with your case use of ssh the connection can also just hang on occasion, so I suppose a menu item to kill and restart the command before it exits would be useful. I'm not sure what's the best thing to do about the first command though. Should roxterm try to kill it at all? I suppose it'll get a HUP when it gets detached from the terminal anyway. What if it doesn't respond to TERM or HUP and holds a resource that blocks a new instance? How long should roxterm wait before sending a KILL, and should it prompt?

Original comment by: realh

[realh]

I think the latter reruns the -e command rather than what's configured by the profile...

Yes, this does work, but then I ran into bug #2810505.

...the connection can also just hang on occasion, so I suppose a menu item to kill
and restart the command before it exits would be useful...

Good point. Yes.

Should roxterm try to kill it at all?

What is the lineage of the command? Are you spawning a child shell and launching the command within that?

If so, and you plan to kill the parent shell, then as you say the grandchild process with get a HUP signal. Until you receive feedback from users indicating otherwise, I'd stick with that approach, as it may only be a one in a thousand corner case where additional termination effort is required.

If it does become necessary, the best approach might be one that uses stages of escalation, with timeouts, and confirmation dialogs. So for example, if after 5 seconds the process hasn't exited, you put up a dialog informing the user of this, giving them the option to wait, try harder, or cancel. If it's a stuck process, they try harder. If it's a bogged down machine going into swap, they wait.

Original comment by: tmetro

[realh]

I'm going to pass on this, at least for now. I think it's quite an esoteric requirement, and supporting it in a nice manner could lead to complications (like a dialogue with a "Don't show this again" option).

Original comment by: realh

[realh]

I added a "Restart command" after all.

Original comment by: realh