Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: NinjaCyborg on February 16, 2021, 07:42:36 PM
-
So the convention for C signal is 'stop what you're doing and exit' and D signal is I think 'stop your batch job after the current step completes' but has there ever been a convention for what the E and F signals should do?
-
https://wiki.amigaos.net/wiki/Exec_Signals
SIGBREAKB_CTRL_C
The SIGBREAKB_CTRL_C signal bit is used extensively as the general purpose "Break" signal. It is used by all shell handler commands and many applications to invoke a normal exit of the program. It is up to all applications to follow this recommendation.
Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_C signal bit from any source.
SIGBREAKB_CTRL_D
The SIGBREAKB_CTRL_D signal bit is used mostly by the shell handler to stop execution of a script file or non-interactive stream. It may also be used by applications.
Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_D signal bit from any source.
SIGBREAKB_CTRL_E
The SIGBREAKB_CTRL_E signal bit is not currently used by the shell handler but may be used by some other handlers, OS subsystems or multi-process applications for general undefined inter process signalling.
Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_E signal bit from any source.
SIGBREAKB_CTRL_F
The SIGBREAKB_CTRL_E signal bit is not currently used by the shell handler but may be used by some other handlers, OS subsystems or multi-process applications for general undefined inter process signalling.
Applications should never crash or generally misbehave when receiving a SIGBREAKB_CTRL_F signal bit from any source.
There, now you can yell at me again :)
-
Yes I read that and see that it doesn't say what D, E and F should do, but that doesn't mean there hasn't been some unofficial convention in the past, or attempts at one.
But thanks for posting a somewhat helpful answer for a change. Since you have a view on everything what would you think would be useful? Show/Hide a GUI? Switch between quiet output and verbose output on the receiving processes stderr? some kind of 'confirm you haven't crashed please' heartbeat? release any memory you're not using if you can?
-
This is a great question, and a much welcomed thread. Although referring to a application hardly implies a set covention, for the sake of the discussion it may be worth noting that the AmiTCP network service responds to CTRL-F, AFAIK, by re-reading its configuration settings. That being said, I'm not sure if any other AmigaOS programs behave the same way.
-
According to the Metacomco's "Introduction to Tripos" document (published in 1986) CTRL-E and CTRL-F use cases are documented in the Tripos Programmer's Reference Manual.
...
I just searched the Tripos Programmer's Reference Manual and there were no CTR-E or CTRL-F use cases or examples.
On the Developer CD 1.1/2.1 there is a document (amcx.txt) that says that CTRL-E was initially used as a commodity break key. There are also examples where CTRL-F is used for waking up an application - CTRL-F causes the application to process messages arrived to its message port.
-
Thanks.
While 'reload new settings' is an interesting one I think it could be argued the proper way to do that is the IPrefs way, to monitor the file and automatically reload settings when it changes.
Taking the 'service manager view' one can also argue that instant update is not ideal for all use cases, manually edited settings files might have mistakes in them that should be validated or tested first, so in the case of a TCP stack I can see why it they've done it as an explicit reload. For something like a TCP Stack you don't necessarily want it to load new settings implicitly as that could break in-progress connections, and neither do you want to exit and relaunch it as that's a heavyweight activity compared to a reinitialise, since it wouldn't need to close and reopen libraries, free and reallocate memory, and apps that depend on it might not need their existing resources terminated. So a soft-reset function is desirable for 'server'-like use cases. Not that AmigaOS runs many servers and services in the normal sense.
It seems like we have
Ctrl C - terminate immediately
Ctrl D - terminate at end of your current job
Ctrl E - not allocated
Ctrl F - reinitialise yourself but don't exit
I'd vote for Ctrl E being a 'confirm you are there' signal which the correct response is to send a Ctrl E signal back to the process you received it from. In this way a task manager could ask software to confirm to hasn't crashed or stuck in a busy loop. Or alternatively it could be used for asking a process to yield or reduce it's own task priority perhaps because it's using too much CPU. But then, the OS can do that arbitrarily.
-
You cannot make a convention from just one example.
Ctrl-X signals are for long running shell applications. There are not many of them out there. Usually a long running application either has a GUI or is a commodity.
In pre-commodity times you could have used Ctrl-X signals as easy hot keys.
The only app I know which uses Ctrl-X signals other than Ctrl-C is Sahimi. It uses Ctrl-D to reset the console, Ctrl-E to empty its buffer and Ctrl-F to save the buffer to a file. Just like I said before, easy to use hot keys.
-
True true, it's just a thought exercise my friend. No one's trying to dictate anything. Thanks for pointing out Sashimi, I had forgotten it. One could argue Sashimi is following that pattern - Ctrl D - finish your current activity and reset yourself, Ctrl - F end what you're doing and reinitialise yourself. Admittedly the difference between those two is subtle.
-
When you run a script, and want to break it, you typically end up sending ctrl-d + ctrl-c
- ctrl-d tells the shell to break the script and stop running more commands, but the currently running program stays running.
- ctrl-c tells the running program to break and exit.
If you, say, swap it around, and send ctrl-c before ctrl-d, you will break the currently running program, but the script may then just jump on to the next command and your ctrl-d wil just "hang around" till that program is done.
-
I think everybody here already knows that.
-
I think everybody here already knows that.
Good, but sometimes ctrl+c is enough to break the shell script too, and sometimes ctrl+c will _never_ break the shell script.
Does everybody here know the reasons for these cases as well?
-
I would assume because the program responding to Ctrl-C exits with a return code greater than the failat value so the script terminates.
-
I would assume because the program responding to Ctrl-C exits with a return code greater than the failat value so the script terminates.
Correct - except that this doesn't always work.
The shell of OS 3.1.4 has a bug, so FailAt levels are ignored, and scripts will continue regardless, so... make sure to install OS 3.1.4.1 update, run SetPatch and make sure shell is 46.21 (or newer) before you do anything fancy.
@ NinjaCyborg
Look! I did it again! Another dig at ThoR! :D
-
I think everybody here already knows that.
Looks like buddy Tygre doesn’t understand the difference between ctrl+c and ctrl+d when it comes to script execution - maybe you can explain to him.
https://forum.amiga.org/index.php?topic=75064.msg851630#msg851630
-
Stop being a dick.
-
Mind your language, avoid personal attacks and stay on topic - ctrl+f is not equivalent sending “quit” (as suggested in that other thread.)
-
I noticed using Ranger than several OS4 system processes listen to ctrl E and Ctrl F. Not sure what for.