HN Explorer

13 comments

[ 1.9 ms ] story [ 62.6 ms ] thread
daniellockard
This requires your bash have networking support compiled in (some distros don't, or didn't in the past), I'm not sure why you wouldn't use nmap, or even netcat: `nc -z $my_host_to_scan 1-1023`
pkrumins
Just playing around with bash. Great remark about networking support!
RickHull
Why do these checks sequentially? I'd be interested to see the opportunities for parallel requests in bash.
pkrumins
Didn't think of that. Pretty good idea!
jebblue
This is very cool, thanks for sharing!
rakiru
It's kind of cheating to use perl for some of it, don't you think? I know this was just an experiment, and the actual networking part is pure bash, but the title is still misleading. Still, this is certainly interesting and not something I'd considered.
icebraining
That bothered me too, so I implemented alarm(2) in bash. Beware of bugs, though:

  function alarm() {
    timeout=$1; shift;
    bash -c "$@" &
    pid=$!
    {
      sleep $timeout
      kill $pid 2> /dev/null
    } &
    wait $pid 2> /dev/null
    return $?
  }


  alarm 1 "echo >/dev/tcp/google.com/230" && echo "Y" || echo "N"

  //this prints 'N' in ~1s

  alarm 60 "echo >/dev/tcp/google.com/80" && echo "Y" || echo "N"

  //this still returns almost immediately and prints "Y"
pkrumins
Really cool. I couldn't figure this out!
reddit_clone
Cool. Would you be able to annotate this code for non-adepts?
icebraining
Sure. So, the basic idea is:

1. we launch a new bash process to actually run the code (in this case, connect to a host) and store its ID so that we know how to kill it

2. we immediately launch a second process (the block { ... } &), whose only job is to wait for X seconds and then kill the first process

3. then we wait for the first process to end (either because it just finished, or because it was killed before it could) and return its return code.

  function alarm() {           
    timeout=$1; shift;        | this just copies the value from the first argument and removes that from the argument list
    bash -c "$@" &            | here we launch the first process, as in (1) above, passing it all the remaining arguments
    pid=$!                    | .. and store its ID
    {                         | so, this is the second process
      sleep $timeout          | we wait the given number of seconds
      kill $pid 2> /dev/null  | and then we kill the first process, if it still exists
    } &                                
    wait $pid 2> /dev/null    | 'wait' blocks the execution of the function until the first process terminates, and puts its return value into $?
    return $?                 | this just returns the same that the first process did, so that the caller can know if it was successful or not
  }
kill-9-1
backgrounding a job to sleep/kill a pid isn't necessarily a great idea imho. here, if the port in question is open then then you will pass the wait relatively quickly, but you still have a timer set to kill the pid. A short timer probably won't cause an issue, but the longer you wait the more likely it becomes that the kernel will assign that pid to a new process that you probably don't want killed. especially if you are launching two new pids for each possible port.
icebraining
I considered that, but didn't have time to think about a proper solution. Using bash's own job control instead of regular kill would probably be better.