This question already has answers here:
The Bash command :(){ :|:& };: will spawn processes to kernel death. Can you explain the syntax?
(4 answers)
Closed 8 years ago.
Ok, so someone "challenged" me to enter this into my OSX Terminal, but I have no idea what it would do:
WARNING to the reader: the following line can be harmful; do NOT enter it unless you know what you are doing:
:(){ :|:& };:
Any ideas?
It's a fork bomb. Don't do it. (Actually, as GB pointed out quickly, the copy here started out as a broken fork bomb. It was missing its final colon.) Still, if someone says, "Try this command" while snickering, and you don't know what it does, common sense says...
Edit: The one you have here is pretty famous as a work of art by Jaromil, a digital artist.
Breaking down the command so it's actually understandable:
:() #Define new function
#named ':'
{ #Begin function definition
#block
:|:& #Pipe the very ':' function through itself,
#creating two processes, and make the
#resulting copy run in the background
#(the & part)
} #End function definition block
;: #Call ':' for the first time, initiating a chain
#reaction: each instance of ':' will create two
#more instances, ad infinitum
Then again, from my experience Mac OS X happens to have a per-user limit for the number of processes one can execute, so unless you actually have the guts to run the fork bomb under a sudo -s or sudo -i shell, you should be fine.
It does nothing harmful, since Mac OS X has a (per-user) upper bound for number of processes.
Absolutely nothing. It's an incomplete version of the "fork bomb", missing a colon at the end.
Fork bomb!
I mean... fun bomb! Give it a try inside a virtual machine.
On properly configured systems it doesn't do much harm, you should be able to try it.
Related
I may have inadvertently launched a bash script containing an infinite cycle whose exit condition may be met next century, if ever. The fact is that I launched the script, as I would do with a nohup program, with
bash [scriptname].sh &
so that (as I get it, which is most probably wrong) I can close the terminal and still keep the script running, as was my intention in developing it. The script should run calculation programmes in my absence and let me gather the results after some time.
Now I want to stop it, but nothing seems to do the trick: I killed the programmes the script had launched, I removed the input file the script was getting orders from and - last and most perfect of accomplishments - I accidentally closed the terminal trying to "exit" the script, which was still giving me error messages.
How can I check whether the script is running (as it does not appear in "top")? Is the '&' relevant? Should I just ask permission to reboot the pc, if that will work and kill everything?
Thank you.
[I put a "Hi everyone" at the beginning but the editor won't let me show it. Oh, well. It's that kind of day.]
Ok, I'll put it right here to prove my stupidity, as I wandered the internet shortly (after a long wandering before writing this post) and found that the line:
kill -9 $(pgrep -f [SCRIPTNAME].sh)
does the trick from any terminal window.
I write this answer to help anyone in the same situation, but feel free to remove the thread if unnecessary (and excuse me for disturbing).
Good you found it, here is another way if you do not use bash -c and run it in current shell not a separate shell.
# put a job in background
sleep 100 &
# save the last PID of background job
MY_PID=$!
# later
kill $MY_PID
This question already has answers here:
When to wrap quotes around a shell variable?
(5 answers)
Closed 6 years ago.
I am doing some pentests against one of my websites that is currently being built (a school project)
And I am trying to make sure it's security at it's best.
(Yes, I do have the correct parameters and the site is vulnerable to SQLi Injections.
It does continue it's scan but it will then ask the [y/n] and I choose [y] and it just stops and doesn't scan. I've tried doing a fresh clone of sqlmap and that didn't work.
Anything that can help would be appreciated.
root#kali:~# sqlmap -u http://myschoolproject.com/ --dbs
[1] 1372
bash: --dbs: command not found
(It will scan until asked a [y/n])
it looks like the back-end DBMS is 'MySQL'. Do you want to skip test payloads specific for other DBMSes? [Y/n] y
[1]+ Stopped sqlmap -u http://myschoolproject.com/
That sounds like you have a & in there. In bash, foo & bar runs the command foo in the background and bar in the foreground.
So if your URL actually looks like http://myschoolproject.com/index.php?cat=4&attr=95,76, that command is interpreted as
sqlmap -u http://myschoolproject.com/index.php?cat=4 &
attr=95,76 --dbs
The first command runs sqlmap in the background (with a truncated URL); this explains the [1] 1372 part (that's what bash shows then starting a background process). The second command runs --dbs in the foreground (with attr set to 95,76 in the environment); this explains the bash: --dbs: command not found error.
In any case, the solution is to quote the URL with single quotes:
sqlmap -u 'http://myschoolproject.com/index.php?cat=4&attr=95,76' --dbs
Why does the first excerpt succeed and the second fail?
system 'emacs', '--batch', '--quick', '--eval="(require \'package)"'
system 'emacs --batch --quick --eval="(require \'package)"'
(If it matters, I'm executing the code on Mac OS X Mountain Lion with Ruby version 1.8.7 and Emacs version 22.1.1.)
First of all, those two system calls are different in ways that you may not expect. A quick example will probably explain the difference better than a bunch of words and hand waving. Start with a simple shell script:
#!/bin/sh
echo $1
I'll call that pancakes.sh because I like pancakes more than foo. Then we can step into irb and see what's going on:
>> system('./pancakes.sh --where-is="house?"')
--where-is=house?
>> system('./pancakes.sh', '--where-is="house?"')
--where-is="house?"
Do you see the significant difference? The single argument form of system hands the whole string to /bin/sh for processing and /bin/sh will deal with the double quotes in its own way so the program being called will never see them. The multi-argument form of system doesn't invoke /bin/sh to process the command line so the arguments are passed as-is with double quotes intact.
Back to your system calls. The first one will send this exact argument to emacs (note that Ruby will take care of converting \' to just '):
--eval="(require 'package)"
and emacs will try to evaluate "(require 'package)"; that looks more like a string than an elisp snippet to me and evaluating a string literal doesn't do much of anything. Your second will send this to emacs:
--eval=(require 'package)
and emacs will complain that it
Cannot open load file: package
Note that my elisp knowledge is buried under about 20 years of rust and forgetfulness so some of the emacs details may be a bit off.
what is the use of writing the following command at the start of a ruby program ?
#!/usr/local/bin/ruby -w
Is it OS specific command? Is it valid for ruby on windows ? if not, then what is an equivalent command in windows ?
It is called a Shebang. It tells the program loader what command to use to execute the file. So when you run ./myscript.rb, it actually translates to /usr/local/bin/ruby -w ./myscript.rb.
Windows uses file associations for the same purpose; the shebang line has no effect (edit: see FMc's answer) but causes no harm either.
A portable way (working, say, under Cygwin and RVM) would be:
#!/usr/bin/env ruby
This will use the env command to figure out where the Ruby interpreter is, and run it.
Edit: apparently, precisely Cygwin will misbehave with /usr/bin/env ruby -w and try to look up ruby -w instead of ruby. You might want to put the effect of -w into the script itself.
The Shebang line is optional, and if you run the ruby interpreter and pass the script to it as a command line argument, then the flags you set on the command line are the flags ruby runs with.
A Shebang line is not ruby at all (unless you want to call it a ruby comment). It's really shell scripting. Most linux and unix users are running the BASH shell (stands for Borne Again SHell), but pretty much every OS has a command interpreter that will honor the Shebang.
“#!/usr/local/bin/ruby -w”
The "she" part is the octothorp (#), aka pound sign, number sign, hash mark, and now hash tag (I still call it tic-tac-toe just cuz).
The "bang" part is the exclaimation mark (!), and it's like banging your fist on the table to exclaim the command.
On Windows, the "Shell" is the command prompt, but even without a black DOS window, the command interpreter will run the script based on file associations. It doesn't really matter if the command interpreter or the programming langue is reading the shebang and making sure the flags are honored, the important point is, they are honored.
The "-w" is a flag. Basically it's an instruction for ruby to follow when it runs the script. In this case "-w" turns on warnings, so you'll get extra warnings (script keeps running) or errors (script stops running) during the execution of the script. Warnings and exceptions can be caught and acted upon during the program. These help programmers find problems that lead to unexpected behavior.
I'm a fan of quick and dirty scripts to get a job done, so no -w. I'm also a fan of high quality reusable coding, so definitely use -w. The right tool for the right job. If you're learning, then always use -w. When you know what you're doing, and stop using -w on quick tasks, you'll start to figure out when it would have helped to use -w instead of spending hours trouble shooting. (Hint, when the cause of a problem isn't pretty obvious, just add -w and run it to see what you get).
"-w" requires some extra coding to make it clear to ruby what you mean, so it doesn't immediately solve things, but if you already write code with -w, then you won't have much trouble adding the necessary bits to make a small script run with warnings. In fact, if you're used to using -w, you're probably already writing code that way and -w won't change anything unless you've forgotten something. Ruby requires far less "plumbing code" then most (maybe all) compiled languages like C++, so choosing to not use -w doesn't allow you to save much typing, it just lets you think less before you try running the script (IMHO).
-v is verbose mode, and does NOT change the running of the script (no warnings are raised, no stopping the script in new places). Several sites and discussions call -w verbose mode, but -w is warning mode and it changes the execution of the script.
Although the execution behavior of a shebang line does not translate directly to the Windows world, the flags included on that line (for example the -w in your question) do affect the running Ruby script.
Example 1 on a Windows machine:
#!/usr/local/bin/ruby -w
puts $VERBOSE # true
Example 2 on a Windows machine:
#!/usr/local/bin/ruby
puts $VERBOSE # false
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Spawn a background process in Ruby
Spent a couple days poking at this. I was using ruby 1.8.7 from the OS until recently. I would call a subshell with backticks. The subshell was a bash wrapper that would call run any program in the background with stdout and stderr both closed. It then ran disown to let init take over the process and it would return immediately. This worked great for years, where I would have this looping process kick off jobs in the background and immediately report back "yes, it ran, that's all I am telling you".
I upgraded everything to rvm 1.9.3 and everything's fine except for this trick. I'm starting to suspect it's more of a hack than I want to admit. In 1.9.3, I always get an EPIPE error when I spawn that subshell. It says that it has a broken pipe. I can accept that it isn't going to work in 1.9.3 since it seems kinda gross what I was doing in 1.8.7.
I've tried using the system command and I have tried open3:popen2. They also both throw an EPIPE with me calling the disown wrapper.
#!/bin/bash
# this will crash ruby if you keep trying to read from it.
$* >&- &
disown %1
This is the disown wrapper. In ruby I have something like
r=`/usr/local/bin/disown /usr/local/bin/job.sh`
And when this runs, it throws
/usr/local/bin/runner.rb:88:in ``': Broken pipe (Errno::EPIPE)
If I don't assign the (zero) output to the r variable, the effect is identical. And with the system function and Open3:popen2.
So my goal is to simply run a command from ruby and not wait for it to come back. It takes several hours and I do not need to track it, just spawn it. I might try a worker thread pool if it begins to sound like ruby can no longer do this, or if my disown wrapper is too heinous to get any approval. Ok. Thanks.
*edit: Thanks for the great answers everyone. I think Casper showed me that if I had a better handle on the ruby lingo, I probably would have zeroed in on this. Sorry if this a little pedestrian. I appreciate the quick answers, everyone!
Well, you answered yourself: Process.spawn:
Process.spawn("something");
in Ruby 1.9.3， u can use
Process.fork do
# do your long time job
end
Check out the daemons gem. Then you can do:
require 'daemons'
Daemons.run('some_script.rb')