Dull Directory Colour in Ubuntu Server

One of my problems with the latest version of Ubuntu server is the default colour for the ls command, I'd never engaged with this before, but it's a dark blue.  It's probably always been dark blue, if you perform ls with "--color=auto" you'll see it's probably dark blue, but the server always left it without the default colour... until now.

And I can't see the dark blue very well, I have reduced the amount of blue light on all my screens and dimmed things down for long hours in front of the screen, so dark blue really really doesn't work.

I have to change my folders, but I don't want to overload everything... Only the directory colour, if you take a look at the ~/.bashrc file then you will see ls colur defaults to auto:

But, I figured out that the colour will default and THEN another alias will over ride... So, I leave the auto alone and add a new alias at the bottom of the file:

This is setting the "di"rectory to colour 33, which is orange...

Reboot and this is what I now see...

The cyan colour for the files is coming from the auto, the highlight around tmp likewise.  But the orange is coming from my alias... Lovely, now I can read the server information even on this dim dim screen... eye candy!

If you want to follow more of this, check out this source.

Bash : Power of Pipes

Subtitle: "Get IP Address Easily"

When I say easily, I mean not so easily, but with the proper tools... Let me explain, it's been one of those days... I've a remote server running some flavour of Linux, and no-one knows it's remote IP Address, they all SSH into the box run "ifconfig" and note down the value, they then plug this into a config (or worse still were baking it directly into some code) and running their services....

The trouble of course being, years later, they're no-longer the programmers nor maintainers of this machine, I am...

And to be frank whenever the IP address changes I don't want to recompile their java code, nor use vi to edit the various configuration files, I want a script to at least update the settings automatically.

I therefore changed their code to load the IP address, not hard code it, and used some other scripts to put the IP address into the config file at boot...

The first line of that script is what I'm going to document here... so it starts:

#! /bin/bash

ifconfig | grep inet | tr ' ' '\n' | sed -u '/^$/d' | head -2 | tail -1 > ipaddress.txt

This script gives me a single line of text with the IP Address in it, for the one and only adapter in the machine, if you have multiple adapters you'd have to play about with the grep inet to select the row you want with a head & tail call before moving into the  final location, or whatever...

I wrote this up however, and immediately started to use the IP address.

The net result was a request to explain all this functionality to a colleague... Here's what I came up with.

ifconfig gets us the adapter information...

grep strips off lines we don't want only giving lines for the inet adapter

translate turns spaces into new lines

the sed call removes the blank lines, giving just the IP address and some guff

the first adapter IP address is therefore always the second line of this output

we select the first two lines with head

then select only the latter of these two with tail

and write this to a file

Her reply... "What are the Lines?"....

"What lines?"...

"These | things"....

"They're pipes, I'm piping the information from one program to the next..."

"Oh"

"Do you know what pipes do in Unix and Linux?"

"No"

I sent her to this video... https://youtu.be/XvDZLjaCJuw?t=5m15s

Development : Anti-Hungarian Notation

Whilst cutting code I employ a coding style, which I enforce, whereby I output the scope of the variable being used with a prefix.

"l_" for Local

"m_" for Member

"c_" for constant

"e_" for enum

And so forth, for static, parameter and a couple of others.  I also allow compounds of these, so a static constant would be:

"sc_"

This is useful in many languages, and imperative in those which are not type strict, such as Python.

Some confuse this with "Hungarian Notation", it's not.  Hungarian notation is the practice of prefixing a type notification to the variable name, for example "an integer called count" might be "iCount".

I have several problems with anyone using Hungarian Notation, and argue against it thus. With modern code completion and IDE lookup tools this is really not needed, with useful and meaningful naming of your variables the type is not needed and finally there are multiple types with the same possible meaning... i.e. "bool", "BYTE" and "std::bitset" are they all 'b'?  What about signing notation, so you compound "unsigned long" as "ul" to the name?

It all gets rather messy, a good name is enough.

However, the scope of the variable might change, the scope might not be enforced, and in none strict languages you might have a variable go out of scope and then automatically re-create the value with a blank value, if you don't follow your scopes.

Therefore I can justify my usage and enforcement of this coding standard.

What I can't stand however is when someone listens to my explaining this, they read my coding standards document, they even go as far as having me reject their code during peer review for these reasons, and then they dismiss my comment with the "it's just Hungarian Notation"... Scope is not type, and type does not define scope, don't be fooled!