(
Jump to the original submission)
Wed 28 Jun 2017 02:53:35 PM UTC, comment #8:
just saw this and confirming comment #7 is still valid on 4.2.1 in Windows.
|
Thu 15 Dec 2016 02:05:08 PM UTC, comment #7:
This isssue is still present in Octave 4.2.0. (Windows and Linux)
The behavior from comment #0 to #2 is still the same.
|
Wed 19 Mar 2014 09:58:11 PM UTC, comment #6:
I can confirm comment #5, no issue as in comment #3-#4 when using octave --force-gui. Pilot error, sorry for the noise, thanks for diagnosis.
|
Wed 19 Mar 2014 01:25:08 PM UTC, comment #5:
The last two, comment #3 and comment #4, are unrelated to this bug report. The octave-gui executable is not meant to be run directly, except on Windows systems I think. Use the octave executable wrapper to run the GUI and you should not see these terminal job control issues.
|
Wed 19 Mar 2014 10:55:43 AM UTC, comment #4:
in more detail.
- launch octave-gui as background job (becomes job 1)
job status: [1] Running
- type help dir in octave-gui's command window.
No help output appears in octave-gui command window
job status: [1] Suspended (tty output)
- type fg %1 in launching terminal
output of help dir appears in octave cmd window.
- type q in launching terminal window: help dir is closed in octave command window, normal >> prompt returns in octave
|
Tue 18 Mar 2014 10:13:12 PM UTC, comment #3:
Noticed this issue too. If I launch octave-gui as a background job,
then launch less in octave-gui's command window, I see the job "waiting for input". It seems the less command's input/output descriptors are connected to the terminal that launched octave gui, instead of to the gui's command window.
|
Tue 18 Mar 2014 03:46:12 PM UTC, comment #2:
I have also noticed that is not exclusive to the "less" case. In fact if you run a command that block the prompt (i.e rand(4000)*rand(4000)), and try to close the GUI it will not do. Again if you interrupt the command that is running, it exists but this time with a "octave exited with signal 11" message on your terminal.
IMHO that should be handled so if the user is closing the GUI while a command is running he/she should be asked if the desire is to close anyway and finish the command execution or stay. Missclicks are avoided this way.
|
Tue 18 Mar 2014 03:14:49 PM UTC, comment #1:
Confirmed on Windows too.
I didn't see a message like 'exited with signal 6' but that may be due to Windows.
|
Tue 18 Mar 2014 03:08:56 PM UTC, original submission:
I have noticed that if the pager "less" is active in the interpreter it is not possible to close the GUI and exit normally. Then if you exit the pager, the GUI finally exit with a "octave exited with signal 6" message.
Just rand(300), then try to close the GUI and finally close pager to reproduce the situation.
I think it has something to do with the GUI waiting indefinitely for the less process to end. Maybe a signal should be sent to less for killing it at that point.
|
(Note: upload size limit is set to 16384 kB, after insertion of the required
escape characters.)
Attach File(s):
Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one
Digest:
bug dependencies.
Follow 5 latest changes.