Fix signal handler

[posva]

Fix signal handler

[posva]

I intentionally check it after each loop so an image doesn't get half printed
I'm afraid your knowledge is way higher than mine and that I cannot see what will this bring to catimg. I really appreciate it as I'm learning many interesting things but I cannot see any any benefit from using the sig_atomic_t. To me this seems a bit overkill.
However if you change the code, create a PR and prove the code have been improved in efficiency or in error handling, I'll merge it.

I'm going to add an option for the number of loops so that line will be needed

[elfring]

… I cannot see any any benefit from using the sig_atomic_t.

The reuse of this data type is one of the preferred ways for the portable data exchange with your signal handler. How do you think about to improve software portability a bit here?

An other software design option would be to delegate signal handling or the image file processing to another thread, wouldn't it?

[posva]

ok for the portability. Having multiple threads for catimg just to handle the sigterm or any other signal is overkill, don't you think 😅

[elfring]

Having multiple threads for catimg just to handle the sigterm or any other signal is overkill, …

It depends on user expectations for your software application. In which time frame would you like to see the appropriate response for the event "SIGINT"?

[posva]

It depends on user expectations for your software application

Well, nobody complained about it yet.

In which time frame would you like to see the appropriate response for the event "SIGINT"?

At the end of an image/frame for a GIF and anytime for a normal image. Although this may vary on the terminal size. I guess I'll etablish a pixel count. I'll run some test and call the handler after that many pixels are displayed

[elfring]

I guess I'll etablish a pixel count.

Is such an approach really needed?
Will an immediate reaction be usually more appropriate?

[posva]

nope, as I said in the first comment

[elfring]

I assume that there are users who will not like delayed signal handling.

Can the portable data type "sig_atomic_t" be applied at least?

[posva]

I'll see, thanks 😄