Warning: DO NOT attempt the commands listed in this question without knowing their implications.
Sorry if this is a duplicate. I am surprised to learn that a command as simple as
freezes my computer (actually it is lagging the computer very badly rather than freezing, but the lag is bad enough to make one think it has frozen). Typing CtrlC or CtrlZ right after typing this command does not seem to help me recover from this mistyped command.
On the other hand
is a well-known vulnerability that also lags the computer badly to the best and crashes the computer to the worst.
Note that these commands are quite different from the well-known fork bombs.
My question is: Is there a way to interrupt such commands which build up huge amount of shell command line options immediately after I start to execute them in the shell?
My understanding is that since shell expansion is done before the command is executed, the usual way to interrupt a command does not work because the command is not even running when the lag happens, but I also want to confirm that my understanding is correct, and I am extremely interested to learn any way to cancel the shell expansion before it uses too much memory.
I am not looking for how the kernel works at low memory. I am also not looking for
SysRq overkills that may be helpful when the system already lags terribly. Nor am I looking for preventative approaches like imposing a
ulimit on memory. I am looking for a way that can effectively cancel a huge shell expansion process from within the shell itself before it lags the system. I don't know whether it is possible. If it is impossible as commented, please also leave an answer indicating that, preferably with explanations.
I have chosen not to include any system-specific information in the original question because I want a general answer, but in case this matters, here are the information about my system:
Ubuntu 16.04.4 LTS with
bash 4.3.48(1), running a
x86_64 system. No virtual machines involved.
$(yes)command runs in a subshell and, I assume, doesn't return control to the parent shell until the command has finished. Since
yesnever finishes, control isn't returned. Not sure enough to post this as an answer though.