My MySQL command prompt

Earlier this week we had a discussion with fellow DBAs about our mysql prompts, and at the end of the day it showed up, that a lot of us hit the same problem.

The problem is, that when you set up your mysql prompt then ‘\h’ will be resolved to ‘localhost’ when you connect locally – instead the name of your host as you expect it. It always bugs me, and once I spent a good afternoon figuring out how to workaround this.

Well, the workaround is not a big deal, because you can insert any text into your mysql prompt, and after you realise that you can do it, then it is easy: just put the hostname into your prompt with your chosen provisioning tool and that will do.

For example in my puppet installations I use the following setting in the template file from I generate the /etc/my.cnf file:

prompt = "\u@<%= @fqdn %> (\h) [\d]> "

It says: “username@hostname (connected_host) [database_name]” which is really informative. Let me show you this on live servers!

[banyek@db-dev.bfc /home/banyek]# mysql -s
banyek@db-dev.bfc.kinja-ops.com (localhost) [(none)]> \q
[banyek@db-dev.bfc /home/banyek]# mysql -s -h db-dev.xyz.kinja-ops.com
banyek@db-dev.bfc.kinja-ops.com (db-dev.xyz.kinja-ops.com) [(none)]> \q
[banyek@db-dev.bfc /home/banyek]#

You can see that looking at this prompt I am able to say that which username I used, which host I am running the mysql command, what server will I run my commands and in which database I am.

There is also one more thing I want to show you, and that is colorising!

This is not my idea, so here’s the link the superuser article where I’ve read about that, but the idea is simple, use the ANSI escape sequences to colorise your mysql prompt. This could not be done inside a ‘prompt’ setting, but you can to this as creating an alias and echo the whole mysql command line out – where you can use the terminal control sequences.

For example here is an alias which you could check out:

$ alias colormysql=$(echo -e 'mysql --prompt="\x1B[31m\\u\x1B[34m@\x1B[32m\\h\x1B[0m:\x1B[36m\\d>\x1B[0m "')

But I am not really sure if this is generally a good idea. What do you think about that?

Share This:

The way I like to compile my Go programs – Makefile

I was on the quest of searching the Holy Grail of Go programming, and I found something, which I doubt that it is, but close enough – for the first sight.

I have several problems with GO, first, that I write my code on an OSX box, and I’ll run the programs on Linux hosts, so I have to solve the cross compilation; my second problem with Go, that I don’t really like the “There is a GO project folder, and all the GO projects are relying under” approach. It makes githubbing painful.

The first problem of mine is easily achievable since GO 1.5: we only need a GOOS environment variable and we can compile to different OS-es (see more at Dave Cheney: http://dave.cheney.net/2015/08/22/cross-compilation-with-go-1-5) easily.

The second problem is easily solvable too, just we have to start using the GOPATH variable for every GO project we have.

I don’t really wanted to use any external dependencies, so I decided to use ‘Makefile’ – it was proven good for decades. (I don’t know if this applies on bigger projects, but the ones I wrote it is fairly good.)

Let’s check out the makefile of the binlogstreamer!

If you type ‘make’ in the checked out project folder, it will download all the dependencies and build the application there. You can run that locally, test it, etc. If you change the code, then you can compile it again, etc.

On my OSX host, I can build for our linux boxes as well I just type ‘make linux’ and I’ll have the binary which I can run on our servers. I can put the binary to the puppet repository, and git push it.

After I made my changes in the code, and I’d like to push to git, then I just run ‘make clean’ which removes all the binaries, and all dependencies, and leaves just the code there. I can commit and push it when I want.

So far this approach worked to me. Do you have any better?

Share This:

My working environment

I was thinking if my work environment would be interesting or not, but I decided ‘yes’ – because I always like reading about others work env.

I am working with Linux/UNIX for more than 15 years now, and I have tried a lot of cool tools, but at the end, I always found myself using the same apps in terminal.

I like the unix philosophy about Do One Thing and Do It Well. I never really use big, bloated software, I like to use my editor for editing files, and my git client to use git. That’s simple.

Continue reading “My working environment”

Share This: