Tag Archives: bash

Uncategorized

Finding Your Router’s Public IP Address

1 Comment

It’s easy enough to find your home router’s public facing IP address (the one your ISP assigns) via a Google search; they even make it the first result on the page. But what if you want to find it via a script?

That’s the challenge I’m trying to solve. What’s more, I want to do this without calling something on an external service. I’ll only be looking it up once every five minutes or so, but I’d prefer to not be a nuisance. (And if something goes wrong and my script runs in a tight loop, I’d rather not have the polling hammer someone else’s server.)

I found a script on the Linux & Things blog which almost does what I want. That script doesn’t quite work for me though, my route command doesn’t flag the default gateway.

But that’s OK, the bulk of what that script does is to look up the local network’s name for the router. That’s a nice bit of robustness, just in case the router’s name does change for some reason (e.g. switching from Fios to Comcast, you’d get a new router and the new router would likely have a different default name). But for my purposes, it’s good enough to know that the router’s name is always going to be Fred. (No, not really, that would be silly. My router’s real name is Ethel.)

So from a bash prompt, we end up with this snippet of code:

external_address=$(nslookup Fred.home | grep Address | tail -1 | awk ‘{print $2}’)

That one-liner really breaks down to five parts.

nslookup Fred.home looks up Fred’s entry in the local DNS. What I get is something similar to:

Server: 192.168.1.1
Address: 192.168.1.1#53

Name: Fred.home
Address: 192.168.1.1
Name: Fred.home
Address: 172.217.8.14

Now none of that’s my real network information, but what we’re after is that last “Address” line.

Piping the output of nslookup through grep Address throws away every line which doesn’t contain the word “Address”, leaving this:

Address:        192.168.1.1#53
Address: 192.168.1.1
Address: 172.217.8.14

Getting closer, next, it gets piped through tail -1 which grabs just the last line:

Address: 172.217.8.14

Excellent! That’s almost what we want.

The next step in the chain is to run it through awk '{print $2}' which uses the AWK tool to output just the second token in the stream.

Finally, the entire thing is wrapped in the $() operator, which captures the output of those four steps and allows us to assign them to the 

external_address

variable, which allows the external address to be used elsewhere:

external_address=$(nslookup Fred.home | grep Address | tail -1 | awk ‘{print $2}’)
echo $external_address
172.217.8.14

This (obviously) runs at a bash prompt. I’ve tried it out on Ubuntu and the Windows Subsystem for Linux, though I can’t imagine it wouldn’t work on other distributions as well. Most of the magic in this is text parsing. The Windows version of nslookup provides similar output, just formatted differently; there’s no reason a PowerShell script couldn’t do some similar processing to find the address.

Uncategorized

Two New Commands

I enjoy learning new things. When I do, I’ll try to write them down in case others may perhaps also find them useful. If nothing else, the notes may help me when I’m wondering, “How did this get solved last time?”

My team at work is in the process of switch from Subversion to Git and GitHub. Git is new ground for many of us, as is the bash prompt (On Windows, Git includes a full-fledged bash prompt). Doing some troubleshooting today, I learned some new new things about both tools.

Pretty git logs

The first was a new Git command:
 git log --graph --oneline

This creates a wonderful ASCII-art timeline, showing all your commits and showing how files have been merged into the project.

For a project of any complexity, this simple visualization is wonderful for understanding the flow of changes and merges by multiple developers. Check out this snippet from PhantomCSS for example:

blair@Squawk MINGW64 ~/test
$ git log --graph --oneline
* 20db940 0.10.4
* a482cc3 Merge pull request #127 from raveclassic/master
|\
| * bbbaa22 fixed TypeError when calling phantomcss.compareAll() #68
* | e44196e Merge pull request #125 from shadowfiles/extension-settings
|\ \
| * | 28a397f Added option to specify the suffix names of screenshot types.
| |/
* | d8479cf Merge pull request #124 from renanborgez/patch-1
|\ \
| |/
|/|
| * 4b0913f Update README.md
|/
* 84945e5 0.10.2

 

Commit 4b0913f (near the bottom) updates the README.md and is then meged back in commit d8479cf.  Meanwhile, a separate developer is adding new functionality in commit 28a397f, merges two pull requests in commits e44196e and bbbaa22 before everything comes back together in a482cc3

It’s a bit cryptic at first, but much easier to fathom than the straight up git log.

The same format also appears, in a non-text based format, in the gitk tool.

A new (to me) bash command

The other new command was from bash. I’ve known for a while that your command line history is stored in ~/.bash_history, but I didn’t know what it was good for aside from presumably powering the up-arrow / down arrow line-at-a-time history.

Turns out that the history command also displays your command line history, and it’s waaaaay more convenient than typing
more < ~/.bash_history
As a bonus, if you have multiple terminals open, this command is guaranteed to show the history for the current window rather than the one most recently closed.

Uncategorized

Problem: chmod is ignored in the Git Bash prompt

So here’s a strange one that had me baffled for a bit – the chmod command is pretty much a null operation from the Git Bash prompt (MingW64). This initially showed up on a script for launching a Docker container, but as nearly as I can tell, it happens for any shell script.

So, we have a simple script that prints out “Hello World!”.

blair@Squawk MINGW64 ~/test
$ cat foo
echo Hello World!

Simple enough. Now the thing is, I want to make this script executable. Now this particular Bash implementation will let me run ./foo and it’ll execute, but my real use case (running a Docker container) is going to have a somewhat longer name. Just as a matter of convenience, I’d like to to type just the first few characters, press tab, and have the filename expanded. And besides, your executable files should always be marked as executable.

blair@Squawk MINGW64 ~/test
$ ls -l
total 2
-rwxr-xr-x 1 blair 197121 28 Oct 18 00:20 bar*
-rw-r--r-- 1 blair 197121 18 Oct 18 00:10 foo

blair@Squawk MINGW64 ~/test
$

OK, this is an easy fix, I just need to run chmod and set the execute bit to on, right?

blair@Squawk MINGW64 ~/test
$ ls -l
total 2
-rwxr-xr-x 1 blair 197121 28 Oct 18 00:20 bar*
-rw-r--r-- 1 blair 197121 18 Oct 18 00:10 foo

blair@Squawk MINGW64 ~/test
$ chmod 744 foo
blair@Squawk MINGW64 ~/test
$ ls -l
total 2
-rwxr-xr-x 1 blair 197121 28 Oct 18 00:20 bar*
-rw-r--r-- 1 blair 197121 18 Oct 18 00:10 foo

The execute bit didn’t change. Maybe I need to use the u+x syntax instead?

$ chmod u+x foo
blair@Squawk MINGW64 ~/test
$ ls -l
total 2
-rwxr-xr-x 1 blair 197121 28 Oct 18 00:20 bar*
-rw-r--r-- 1 blair 197121 18 Oct 18 00:10 foo

Still no luck. So why is bar marked as executable? What’s the difference between these two scripts? The answer turns out to be one line of code:

blair@Squawk MINGW64 ~/test
$ chmod u+x foo
blair@Squawk MINGW64 ~/test
$ cat bar
#!/bin/sh
echo Hello World!

Do you see that first line, where it says “#!/bin/sh”. That’s how Bash knows what interpreter to pass the script to. It also turns out, in this particular implementation, that’s how Bash knows the file contains an executable script instead of just text.

So we modify foo, and get this result:

blair@Squawk MINGW64 ~/test$ cat foo
#!/bin/sh
echo Hello World!
blair@Squawk MINGW64 ~/test
$ ls -l
total 2
-rwxr-xr-x 1 blair 197121 28 Oct 18 00:20 bar*
-rwxr--r-- 1 blair 197121 18 Oct 18 00:10 foo*

(Image credit: Screenshot by ThatBlairGuy)