everything wrong with free software

 "obedience breeds foolishness"

### avoiding-unwanted-sigint-from-stray-ctrl-c-presses *originally posted:* aug 2021 hello, trsec-- did you know that roy lied to you about me coming back? hey, its not like hes ever going to show you this page anyway. he pretends not to know the address and yet hes made videos where he talks about the content. but thats not what this is about. since youre not going to read this (and im not going to send it to you) i can hardly say im doing this for you, so im doing it for those who do read it. but yesterday you said: ``` Techrights-sec accidentally pressed ctrl-c in the wrong window ... again###### Aug 17 15:11 Techrights-sec there ought to be a way to trap such signals Aug 17 15:11 Techrights-sec dia-1990-2016.htm Aug 17 15:11 Techrights-sec probably something but not important. I was working on the above. Aug 17 15:14 ``` whether youre using gnu/linux or openbsd (which despite what roy says, comes with x and NO, you dont HAVE to run startx-- hes just trolling) you can fix most of the problems with this that actually exist. how easy that is depends on the specifics: 1. its trivial to prevent this happening with most gui applications. note that occasionally i run applications from a term specifically so that i can kill them easily with ctrl-c, but i can appreciate the desire to achieve the opposite goal. 2. its fairly trivial to prevent this happening with a number of non-interactive text-based programs. 3. many interactive text-based programs will ignore ctrl-c by design (try ctrl-c from vi). 4. its tricky (but sometimes possible) for interactive text-based scripts, depending on the interpreter or shell. ### gui programs if you start your gui program with & at the end of the line, you will probably find that ctrl-c doesnt affect it. thats really simple and that may solve your problem immediately. note that im already in the habit of doing this, for other reasons. when i dont it is an exception. ### non-interactive text-based programs if you have a program running and it does not require keyboard input, running it with & will have a similar effect. this is slightly different from the gui program because the gui has its own output that continues after you close the term with ctrl-d. because the whole point of the non-interactive program may or may not be to display output or logs, it is still "vulnerable" to the term window closing with ctrl-d. your program would still run, but depending on your shell session options you might not be able to get back to displaying the output. if the point of the program is to process data or compile code, or something of that nature, then ctrl-d and ctrl-c will generally not send sigint to the process-- and closing the term wont stop it from running. if it is a loop and you want to stop it, you will have to shut it down using the kill command or similar. ### interactive text-based applications many interactive text-based programs trap ctrl-c and will either ignore it or do something other than immediately sigint, by design. vi is one example. ### interactive text-based scripts it is possible to create a text-based script in various environments that will not shut down immediately when ctrl-c is pressed, although this is less likely to solve your problem than the other solutions (unless youre designing a script that doesnt sigint when you hit ctrl-c). a good guess is that designing a script that ignores ctrl-c will solve all your problems at once, but it probably wont. for example, you can easily write a python script (or shell script) that traps KeyboardInterrupt, but it doesnt disable the key combination or eliminate its effect, it simply traps it. ill explain the difference. you can write a script that carries on after ctrl-c is pressed, and you can write a script that runs some other process. but even though ctrl-c wont stop the script, it may stop the part of the script that is presently running (including the shell call to another program) but then your script will be able to pick up on the next step or iteration. it will effectively "ignore" (more accurately, process differently) the ctrl-c for itself but not for the program youre trying to "protect" with it. this is why & is usually the better option. all the same, if you want to create a script that will not cease immediately when ctrl-c is pressed it is often possible to do so-- look up the details for your language or shell of choice. it probably wouldnt have helped in the example you complained about, and thats why it was mentioned later instead of first. ### misc details * "but im running tmux!" i dont really bother with the functionality of tmux, as its github-based. i know gnu screen isnt as fancy, ive tried both. im not certain tmux is any worse than gnu screen in terms of the issue this article is about. * "but im running gnu screen!" i tried it right before writing this, gnu screen does not appear to sigint when you press ctrl-c. i would have listed it as a solution if i thought it would help with this, but i dont think it makes this any worse. * i am aware that ctrl-c sending sigint is a desired functionality, and i use it for that purpose. this article is about what to do when the user does not want the default behaviour. => https://wrongwithfreesw.neocities.org