by ·0 Comments

The following is a suggested setup of the Git configuration file (_~/.gitconfig):

[user]
    email = my mail address
    name = Roland Kluge
[core]
    editor = vim
    excludesfile = ~/.gitexcludes
[branch "master"]
    mergeoptions = --no-ff
[alias]
        l = log --graph --pretty=oneline --abbrev-commit --decorate
        lt = log --topo-order --graph --pretty=oneline --abbrev-commit --decorate
[color]
        # turn on color
        diff = auto
        status = auto
        branch = auto
        interactive = auto
        ui = auto
[color "branch"]
        current = green bold
        local = green
        remote = red bold
[color "diff"]
        meta = yellow bold
        frag = magenta bold
        old = red bold
        new = green bold
[color "status"]
        added = green bold
        changed = yellow bold
        untracked = red
[push]
        # 'git push' should only do the current branch, not all
        default = current
[branch]
        # always setup 'git pull' to rebase instead of merge
        autosetuprebase = always
[alias]
        st = status
        ci = commit
        br = branch
        co = checkout
        df = diff

by ·0 Comments

Show one’s own/other’s groups

groups
groups LOGIN

Show all groups on the system (with group id):

cat /etc/group | less

Create new group

groupadd GROUP

Add user to group

usermod -G GROUP -a USER

Assign a specific home directory and shell to a user

usermod -s /bin/bash USER
usermod -d /tmp USER

If the user shall only be allowed to do SCP/SFTP transfers, then an appropriate login shell is scponly.

 

 

 

by ·0 Comments

When downloading large files with scp, it is really annoying, if the download process stalls at 90+%, because it seems that you have wasted your time and scp leaves you with a broken file. Having encountered this problem, I was lucky enough to find this post which explains a remedy: Use rsync in order to complete the interrupted download.

Assume you downloaded a file with scp like this:

scp user@hostname:/path/to/file /local/path/to/downloaded/file

then you can continue the download as follows (note the –partial option):

rsync --partial --progress --rsh=ssh user@hostname:/path/to/file /local/path/to/downloaded/file

Rsync finds out that a large portion of the file is already there and continues where scp once has stopped.

Links

  • [1] Article with solution

by ·0 Comments

Log4J is a widely used logging library for Java. With the release of version 1.2.15, some dependencies were introduced that are not deemed necessary by some people [1]. The developers did not – for what ever reason – mark these dependencies as optional, even though they were not available in some common Maven repositories.

The following snippet demonstrates how to exclude transitive dependencies in Maven, applied to the case study of the transitive dependencies com.sun.jmdk:jmxtools and com.sun.jmx:jmxri.

<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.15</version>
  <exclusions>
    <exclusion>
      <groupId>com.sun.jdmk</groupId>
      <artifactId>jmxtools</artifactId>
    </exclusion>
    <exclusion>
      <groupId>com.sun.jmx</groupId>
      <artifactId>jmxri</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Links

  • [1] Mailing list entry stating that some dependencies are unnecessary
  • [2] Maven reference: Optional dependencies and exclusions

by ·0 Comments

From time to time you want to take a look at a file in the past of your Git repository’s history. The following instructions will tell you how to see (and save) a file at a certain commit in the Git history.

Finding the right commit

Depending on the use case there are different ways of finding the commit you want to take a look at. In any case, after this step you will have a commit id or a branch-relative index which can be used to refer to the desired commit.

Referring to recent commit

If you know that the file was in the desired state in the previous, last but one, etc. commit, you can use the “~ operator”:

  • previous commit: HEAD~1
  • last but one commit: HEAD~2
  • head of certain branch: branch123
  • commit before head of branch: branch123~1
  • etc.

Listing files under version control

The command git ls-tree shows you the files which were under version control at a certain point in time:

git ls-tree --name-only HEAD~1  # non-recursive
git ls-tree -r --name-only HEAD~1  # recursive

Deleted files

Suppose you have deleted the file and want to know in which particular commit you deleted it, then the following command will be helpful, which prints out all log entries which contain a delete instruction (you may search as normal with the “/” operator):

git log --diff-filter=D --summary

Git bisection search

If you don’t know the exact version (commit) of the file, but given the file in some state, you can decide whether the appropriate version has been created rather before or after a given one. In this case the bisection search of Git may help: You tell Git a range of commits which surely “enclose” the desired version of your file. The most recent commit is called the bad state and the oldest commit is called the good state, because the bisection search is meant for finding a commit which introduced a bug which has not been there at some point in the past. In our setting, we are not looking for a bug but for a particular version of a file.

git bisect startgit bisect bad # uses the HEAD
git bisect good <commit id some time in the past>
# e.g., Bisecting: 113 revisions left to test after this (roughly 7 steps)

The bisection search will place you at the “center” between good and bad (you can also visualize the situation with the command git bisect visualize). And now you can examine the file in question whether you think the change is in the future or the past of this commit. In the former case (“future”), our we need to tell Git that the current state is good (“bug” in the future):

git bisect good

Likewise, in the latter case we find that the “bug” is in the past and tell Git so:

git bisect bad

Iterate, until you are done. Then, or if you would like to abort the bisection, type:

git bisect revert

Restoring the file

Now that you have the commit of your choice, use the git show command to display or store the file.

git show HEAD~3:README.txt # show the file contents
git show HEAD~3:README.txt > /tmp/README.txt # store the file contents

shows README.txt file in the 3rd last commit of the current branch.

git show issue123~1:doc/html/index.html # show
git show issue123~1:doc/html/index.html > /tmp/index.html # store

shows index.html in the subdirectory doc/html in the state it was one commit before the HEAD of the branch issue123.

by ·10 Comments

For its GPS-enabled camera TZ-31, Panasonic offers to download additional geographic data from the accompanying DVD. Unfortunately, the software for copying the data to the SD card is for Windows only. When I examined the content of the DVD and the SD card after a transfer of European data, I recognized that there is nothing much to implement in order to have a similar platform independent tool.

Note: As pointed out in a comment, my script does not seem to be compatible with the new TZ40, because the directory layout for this camera seems to differ from the TZ31.

How to use it

I host the code of this mini-project on GitHub (download it here) All you need to do is

  1. Download maptool.py and MapList.dat.
  2. Open up a command-line and run the tool. For example: 
    python mapdata.py --regions="6;7;8" --mapdata="/media/dvd/MAP_DATA" --sdcard="/media/sdcard"
  3. Important: The tool will delete the subdirectory PRIVATE/MAP_DATA on the SD card, thereby removing any existing maps.

You get more information about the program options when you start the tool with option –help.

In order to adapt the above command for your setting, you should insert the DVD shipped with your TZ31 and plug in the SD card of your camera.

  • –regions: each global region is assigned an integer between 1 and 10. If you install the official MapTool, then you can browse the regions from within the program or by opening the HTML files which are stored in the program files of the MapTool. As this tool here is meant to work independently from Windows, I extracted the region ids for you (see also –help):
    1 – Japan
    2 – South Asia, Southeast Asia
    3 – Oceania
    4 – North America, Central America
    5 – South America
    6 – Northern Europe
    7 – Eastern Europe
    8 – Western Europe
    9 – West Asia, Africa
    10 – Russia, North Asia
  • –mapdata: the path to you map data which is normally stored in the subdirectory MAP_DATA of the DVD
  • –sdcard: the path to the “root” of your SD card

Links

  • [1] Downloadable code on GitHub

by ·0 Comments

Proved to be quite useful when editing system configuration files (Apache2, etc.). Thanks!

Commenting in blocks of code

Similarly, you may go the reverse direction and comment in blocks of code as follows:

  1. Go to the first line of the block of comments signs you would like to delete: <line>gg
  2. Enable block selection mode: Ctrl+V
  3. Important: Only mark the comment tokens you want to delete, nothing else!
  4. Navigate to the end of the block either with
    • <line>gg or
    • arrow up/down;  j/k
  5. Press d for deletion

(If necessary undo your changes with u)

by ·0 Comments

By default, Maven does not compile any debug information into an artifact. This is (sometimes) reasonable when you publish libraries which you do not want to reveal too much information about. For personal use, however, I prefer to be able to have a look at the full stack trace. Another benefit of adding debugging information is that you can read the original parameter names of methods.

As debug information is added at compile time, the Maven Compiler plugin is responsible for managing this kind of information:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>2.0.2</version>
      <configuration>
        <!-- Necessary in order for the debug levels to be considered-->
        <debug>true</debug> 
        <debugLevel>lines,vars,source</debugLevel>
      </configuration>
    </plugin>
  </plugins>
</build>

Links

  • [1] Reference of Maven Compiler plugin

by ·0 Comments

Depending on your version of Maven, the default Java version assumed by the compiler plugin may be quite old, even as old as not to recognize annotations. When working with annotations you will get compiler errors such as the following:

The method getProgress() of type TextFileReader must override a superclass method

Solution 1

You can configure Maven to accept (-source argument for the Java compiler) and produce byte code for (-target compiler argument) a certain Java version as follows:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>2.0.2</version>
      <configuration>
        <source>1.6</source>
        <target>1.6</target>
      </configuration>
    </plugin>
  </plugins>
</build>

Solution 2

It is even simpler to use properties:

<properties>
  <maven.compiler.source>1.6</maven.compiler.source>
  <maven.compiler.target>1.6</maven.compiler.target>
</properties>

Links

  • [1] Reference of Maven Compiler plugin