POSIX 2008 says:
A program that uses these functions should be written to catch all
signals and take other appropriate actions to ensure that when the
program terminates, whether planned or not, the terminal device's
state is restored to its original state.
about using tcgetattr() and tcsetattr() to change the terminal device's state. In general, which signals need to be handled and what "other appropriate actions" must be taken? If this cannot be answered in general, which signals/actions are appropriate when using tcgetattr() and tcsetattr() to turn off terminal echo?
The point of the comment is that tcsetattr will change the properties of the enclosing terminal. Thus, if you write a program that disables terminal echo and that program exits without resetting the value, then it will be disabled for the duration of the session (unless another program explicitly re-enables it).
The appropriate thing to do is, if you are going to change an attribute, save all of the old values before you change them (and then roll back the changes before exiting). This can be done in a signal handler, which is what the recommendation focuses on.
Related
I want to press a key at any point, causing the simulation to stop without loosing data collected until that point. I don't know how to do the exit command. Can you give me some examples?
I think, WandMaker's comment tells only half of the story.
First, there is no general rule, that Control-C will interrupt your program (see the for instance here), but assume that this works in your case (since it will work in many cases):
If I understand you write, you want to somehow "process" the data collected up to this point. This means that you need to intercept the effect of Control-C (which, IF it works as expected, will make the controlling shell deliver a SIGINT), or that you need to interecept the "exit" (since the default behaviour upon receiving a SIGINT would be to exit the program).
If you want to go along the first path, you need to catch the Interrupt exception; see for example here.
If you want to follow the second route, you need to install an exit handler. Note that it will be called too when the program is exited in the normal way.
If you are unsure, which way is better - and I see no general way to recommend one over the other -, try the first one. There is less chance that you will accidentally ruin something.
Is there any way to find out what was the last Exit Code of an application the last time it run?
I want to check if application wasn't exit with zero exit code last time (which means abnormal termination in my case) And if so, do some checking and maybe fix/clean up previously generated data.
Since some applications do this (they give a warning and ask if you want to run in Safe Mode this time) I think maybe Windows can tell me this.
And if not, what is the best practice of doing this? Setting a flag on a file or something when application terminated correctly and check that next time it executed?
No, there's no permanent record of the exit code. It exists only as long as a handle to the process is kept open. And returned by GetExitCodeProcess(), it needs that handle. As soon as the last handle is closed then that exit code is gone for good. One technique is a little bootstrapper app that starts the process and keeps the handle. It can then also do other handy things like send alerts, keep a log, clean up partial files or record minidumps of crashes. Use WaitForSingleObject() to detect the process exit.
Btw, you definitely want to exit code number to mean the opposite thing. A zero is always the "normal exit" value. This helps you detect hard crashes. The exit code is always non-zero when Windows terminates the app forcibly, set to the exception code.
There are other ways, you can indeed create a file or registry key that indicates the process is running and check for that when it starts back up. The only real complication with it is that you need to do something meaningful when the user starts the program twice. Which is a hard problem to solve, such apps are usually single-instance apps. You use a named mutex to detect that an instance of the program is already running. Imprinting the evidence with the process ID and start time is workable.
There is no standard way to do this on the Windows Platform.
The easiest way to handle this case is to put a value on the registry and to clear it when the program exits.
If the value is still present when the program starts, then it terminated unexpectedly.
Put a value in the HKCU/Software// to be sure you have sufficient rights (the value will be per user in this case).
I'm programming a Windows console application in plain C and using PeekConsoleInput/ReadConsoleInput to get keystrokes from the user and process them.
I need to get the current state of the Caps Lock, Scroll Lock, and Num Lock keys when the program starts, before the user has entered anything. Meaning there would be no KEY_EVENTs in the message queue to process.
Is this possible to do? If so, how? I've looked at most of the functions in wincon.h and nothing seems appropriate.
You can call GetAsyncKeyState three times, and it will usually work, but there are a few cases where it still won't work for you. The arguments for your three calls would be VK_CAPITAL, VK_SCROLL, and VK_NUMLOCK.
I would like the command gdb on program X to instead switch to an existing debugging session of X if it already exists instead of signalling an error "This program is already being debugged" in gud-common-init.
I believe this is important as it makes the behaviour of gdb harmonize with the standard behaviour of most other Emacs interactions such as, find-file, switch-to-buffer etc, thus creating less confusion to the user.
So far I have modified the line containing
(error "This program is already being debugged"))
to instead do
(message "This program is already being debugged")
to at least prevent the error from arising. However, the function gdb does some extra initializations that should not be needed that causes some unnecessary delays. Is this a todo item or have I missed some gud/gdb-function that does this already?
Many thanks in advance,
Per Nordlöw
You can always rename-buffer. This is how I can run multiple gdb sessions on the same executable. It is not automatic but it is an effective work around.
For example if my executable is called pump, then upon running gdb, a buffer named *gud-pump* will be generated which represents the gdb session. From this buffer do meta-x rename-buffer *gud-pump1*
Then invoke gdb again and you will have two GUD sessions, one *gud-pump* and *gud-pump1*. The sessions are separate and should not interfere (although they can interact) with each other.
I noticed that when a process starts for the first time, it statically reads some system parameter info only once and keeps it until terminated
which means,
that if there is some modification to the system parameters already read by the process, they wouldn'y reflect until the process is restarted.
e.g. Launch Notepad and type ';' key on the keyboard. Now change the input language from the langauge toolbar to Spanish. Now again hit the key ';'. Though the Input langauge has been changed to Spanish, the keys are still English (as seen by pressing ';' key).
Ideally on pressing ';' afer the input language is changed to Spanish, we should have noticed 'ñ'.
When we restart Notepad, we notice that ';' results in 'ñ' which means that the Notepad process needed to be restarted to take effect.
Is there some way where the process is not needed to be restarted to reflect the change in the Input method?
Thanks
If a process cares to, it can listen for notifications of changes to various system-wide settings. The wm_SettingChange message comes to mind.
It's a fool's errand to try to make some other process honor setting changes if it hasn't been written to do so. If a program isn't already listening for change notifications and acting upon them, you can't make it act differently.
Notepad probably isn't a good example; it's a pretty simple program, so it doesn't necessarily cover all the details that a good Windows program should.
The "answer" you gave, to refine your question, talks about changing the system's default input language with SystemParametersInfo. When you call that function, it will broadcast the wm_SettingChange message. To be notified of the change, other programs need to listen for that message; do that the same way you listen for any other window messages in your programming environment.
When you receive that message, the wParam parameter will be either spi_GetDefaultInputLang or spi_SetDefaultInputLang; I don't know which. That's you cue to call SystemParametersInfo to find out the new value of the setting. Based on what I've just read in "Languages, Locales, and Keyboard Layouts", you should call ActivateKeyboardLayout using the HKL value you get from SystemParametersInfo.
The process that changes the default input language cannot force other processes to use it. Until they choose for themselves to change their input languages, they will continue using whatever was the language when they started running. That's the distinction between the default setting and the current setting.