Ubuntu Technical

Ubuntu technical problems and solutions reference, a modern cookbook.

Category Archives: Programming

Customized GPG

Gpg encryption is cool. It’s so cool, that I want to keep all my important files (that means back-up files) encrypted on my external storage.

Using gpg is fairly straight forward:

1) Generate a private key.

gpg --gen-key

After answering some standard questions, the key is ready.
Note: You better not forget the password you choose, or else your encrypted files are lost forever.

2) Check you key:

gpg --list-keys

This will display a list of all available keys.

3) Encrypt a file

gpg --encrypt --recipient 'key name' foo.txt

This will generate the encrypted file: foo.txt.gpg

4) Decrypt a file

gpg --output foo2.txt --decrypt foo.txt.gpg

foo2.txt file will be created.

So, until now I presented a quick guide to encrypt/decrypt a file. However, this wasn’t enough for me. I wanted to go a little further. I wanted to be able to encrypt folders as well, and the possibility to delete the original file, and keep only the encrypted one. So, I though I write my own function.
And so, tec was born.

In short tec stands for: tar, encrypt, clean. Long description: Tarballs and encrypts the TARGET using gpg (GnuPG) encrypton. Optionally it deletes the TARGET.

I have created a repository for my function on Gitorious, feel free to check the Projects page and download it if you like.

Just copy tec.sh into /usr/bin, and you’re good to go.

cd <download directory>
sudo cp tec.sh /usr/bin

For general help, type:

tec.sh --help

Basic usage:

# with delete option, to delete the original file, and keep the encrypted one
tec.sh -dr <key> <file>
# without delete option
tec.sh -r <key> <file>

The project is in it’s early phases. Currently it only encrypts. For decryption the standard gpg commands have to be used. I plan to maintain the function, and try to add as much functionality as I can.


Flattr this

Adding custom MAN pages

Recently I was faced with a new issue/challenge: adding custom man pages for a custom/user defined command. This being said, I started to dig into the configuration and structure of the man command.

I will not go too deep into the man theory, there is always Google for it, or the official manual pages:

man man

As I now know, after reading documentation, there are 9 section of documentation for each command. So, it means separate documentation file for each section.

In the following example I will create custom documentation for section 1 (Executable user programs and shell commands) and section 4 (Information on device files). I call the command dummy.

#The following commands create the default structure for custom man pages
cd ~/
mkdir ownman; mkdir ownman/man1; mkdir ownman/man4
cd ownman/man1
vi dummy.1 # Add some documentation here. Example: 1) Documentation for section 1
cd ../man4
vi dummy.4 # Add some documentation here. Example: 1) Documentation for section 4

Now that the structure is in place, the man pages for the the dummy command can be called. The -M option has to be used in order to specify the location of the man pages for the specific command.

man -M ~/ownman dummy
1) Documentation for section 1

 Manual page dummy(1) line 1/66 (END) (press h for help or q to quit)

The default section is 1, so it’s not necessary to be specified here. With specification, the command looks like this:

man -M ~/ownman 4 dummy
1) Documentation for section 4

 Manual page dummy(4) line 1/66 (END) (press h for help or q to quit)

The structure and the call is in place now. But still, it could be tiresome sometimes to remember the path to the man pages, especially if one were to declare multiple locations.

To add the ~/ownman location to the locations man is looking at by default, the configuration file needs to be edited. On Ubuntu this file is: /etc/manpath.config (for Red Hat and Red Hat derivatives, like CentOS and Fedora, the configuration file for man is /etc/man.config)

# need sudo rights for this, as the owner of the file is root
sudo vi /etc/manpath.config

Edit the file by adding a new entry in the MANDATORY_MANPATH section.


If there is a need to specify different man pages path for different command paths, another edit needs to be made, further down in the file. A new entry for MANPATH_MAP

MANPATH_MAP ~/custom_commands_location			~/ownman

Now the simple, straight forward command can be called:

man dummy
1) Documentation for section 1

 Manual page dummy(1) line 1/66 (END) (press h for help or q to quit)


Flattr this

Compress and Extract files with tar.gz

Or simply building a “tarball” as it is sometimes called. Even though this is a trivial task, I found myself quite often looking for the command, better yet for the options, because I tend to forget. So why not look for the command on my own blog.

Creating a tar archive

cd location_of_files_to_be_archived
tar cvzf name_of_archive.tar.gz *

Parameters explained:
– c – create
– v – verbose output
– z – –gzip, –gunzip, –ungzip filter the archive through gzip
– f – use the following file for archive

Note: The f option needs to be the last in the list of parameters. Whatever characters are following f, will be the name of the tarball.

Extract a tar archive

cd location_of_files_to_be_archived
tar xvzf name_of_archive.tar.gz *

Parameters explained:
– x – extract


Flattr this

Using bash to count number of lines of code in a project

As the title suggests, here are 2 ways of counting the lines of code you just wrote, in whatever language. My examples will look into .java files.

To make the result include commented line, in other words, every line in the files.

cd {project location}
find . -type f -name '*.java' -exec cat {} \; | sed '/^\s*$/d' | wc -l

The second command excludes commented out lines. It only counts code, pure code.

cd {project location}
find . -type f -name '*.java' -exec cat {} \; | sed '/^\s*#/d;/^\s*$/d;/^\s*\/\//d' | wc -l


Flattr this

Stop or start BOINC daemon after boot

I have installed BOINC client, to subscribe to some projects meant to discovery alien life or at least some new pulsars.
However, I have noticed that the client, in contrast to it’s Windows counterpart, didn’t have an option in Preferences for auto-start on system boot. Of course it was starting up automatically and that’s not good in my book. So I started digging a little bit, and came across the documentation page

In a nutshell, the “init” script is:


The following commands (with self-explanatory options) can be directly run on the script:

./etc/init.d/boinc-client start
./etc/init.d/boinc-client stop
./etc/init.d/boinc-client restart
./etc/init.d/boinc-client status

As I have now found out, in a Debian-based Linux distributions you use the update-rc.d command to turn a system service (daemon) on or off at boot time (I needed to use the -f force option to remove boinc-client, don’t know exactly why):

# tells the system to start the BOINC client as a daemon at boot time
sudo update-rc.d boinc-client defaults 98
# tells the system not to start the BOINC client at boot time
sudo update-rc.d -f boinc-client remove


Flattr this

%d bloggers like this: