Ebixio

Firewall logs are verbose, and utterly boring to look at. It’s hard to pick out the important parts, like what the IP or destination port was. If you use vim/gvim to view the logs, there’s a syntax file I put together to make them more readable. Get it from https://github.com/gburca/vim-firewall

Here’s a before/after image (click for the full size):

Vim syntax highlighting for firewall logs.

It turns out that monitoring a file with vim is harder than it should be. Scripts such as Tail-Bundle and WatchForChanges rely on vim’s CursorHold events which only trigger once. Unlike tail -f, they only work if you’re active in that vim session and pressing keys to cause CursorHold to re-arm.

tail -f works well, but lacks the syntax highlighting and other features from vim.

Some other options require 2 terminals, or 2 separate scripts.

The solution below is very similar to tail -f. The primary difference is that it only monitors a single file at a time.

Get the latest version from: https://gist.github.com/4a334b61e1c34b438ccd.git

#!/bin/bash

# Usage: vim-tail.sh <filename>
#
# This script turns vim into a `tail -f` equivalent, but with syntax
# highlighting and all the other goodies.
#
# A version of vim compiled with +clientserver is required.
# On Ubuntu 14.04, vim.tiny, vim.basic and vim.nox won't work.
# vim.gtk is compiled with +clientserver, so `apt-get install vim-gtk`
#
# Author: Gabriel Burca <gburca dash github at ebixio dot com>

# Pick one of: vim|view|gvim|gview, etc...
VI=vim.gtk

# A unique name for the server, in case we monitor multiple files.
NAME="TAIL$$"

doForever() {
    # Give the vim server a chance to start
    sleep 2

    # Move to the end of the file
    $VI --servername $NAME --remote-send '<C-\><C-N>:edit!<CR>G' > /dev/null 2>&1 || exit

    while true; do
        # This blocks until the file changes, or the timeout expires
        inotifywait --quiet --quiet --timeout 10 --event modify "$1"
        # 0 = the file was modified
        # 2 = the timeout expired
        if (( $? == 0 || $? == 2 )); then
            $VI --servername $NAME --remote-send '<C-\><C-N>:edit!<CR>G' > /dev/null 2>&1 || exit
        else
            exit 1
        fi

        # It's possible for the file to be modified before we loop back to
        # `inotifywait`, but we'll pick it up on the next round.
    done
}

# Kick off the vim client script in the background
coproc doForever "$1"

# Now start the server
$VI --servername $NAME --remote-silent "$1"
# Nothing below here executes until the `tail` server exits.

Watch Full Movie Online Streaming Online and Download

GEDCOM files sometimes have no indentation. That makes it difficult to read or edit them with a text editor. Using the following simple instructions, you can auto-indent the file so that it is more readable in the vim editor.

Compare the readability of the two formats

Save the next few lines into a file called gedcom_indent. Make the file executable and place it somewhere in your path.

#!/usr/bin/env python

from __future__ import print_function
import sys

for line in sys.stdin:
    line = line.lstrip()
    try:
        level = int(line.split(' ', 1)[0])
        print('\t' * level, end='')
    except:                                                                                                                                            
        pass
    print(line, end='', sep='')

Now add the following 2 lines to your ~/.vimrc file:

autocmd BufReadPost,FileReadPost *.ged %!gedcom_indent
autocmd FileType gedcom set foldmethod=indent nolist ts=4

This tells vim to filter any file with a “ged” extension through the small gedcom_indent filter (which will add leading tabs to the file). The second line tells it to make each TAB count for 4 spaces, and to fold based on indentation.

One of the problems with using git on Windows is that it’s difficult to integrate it with other native (Windows) tools. That’s because the environment git runs in (cygwin or msysgit) refers to files by their UNIX name, but the Windows tools have no notion of where /tmp is for example (and that location can be different between cygwin and msysgit).

When doing an interactive rebase, the editor might be asked to edit a file such as /cygdrive/c/some/path/to/a/file. When doing a diff in git, one or both of the files to be diff’d might be placed by git in /tmp. Windows tools don’t understand such path names.

Fortunately, cygwin ships with a utility called cygpath that can be used to convert between UNIX and Windows paths. Msysgit doesn’t have this utility, but if cygwin’s /bin directory is in your Windows path, msysgit will pick it up and the scripts below will be usable for both cygwin and msysgit.

Here’s a GitEditor.sh script that can be used as a wrapper around your editor:

#!/bin/sh

# Author: Gabriel Burca
#
# Script arguments:
# file-to-edit

FILE=`cygpath -w "${1}"`
"C:/Program Files/Vim/vim72/gvim.exe" "$FILE"

#!/bin/sh

# Author: Gabriel Burca
#
# Script arguments:
# path old-file old-hex old-mode new-file new-hex new-mode

# The old-file path is typically "/tmp/.diff_something" and windows programs
# don't know how to get to "/tmp"
# We use cygpath to convert to something windows programs understand.

OLD_FILE=`cygpath -w "${2}"`
NEW_FILE=`cygpath -w "${5}"`
"C:/Program Files/WinMerge/WinMergeU.exe" -e -ub "$OLD_FILE" "$NEW_FILE"

[diff]
external = "C:/Utility/GitExtDiff.sh"
[core]
editor = "C:/Utility/GitEditor.sh"

The vim installation that comes with msysgit is missing a number of syntax file dependencies. In addition to what is installed by default, C:\Program Files\Git\share\vim\vim72\syntax should also contain diff.vim and nosyntax.vim. Without these vim will not display properly and will issue warnings that it’s unable to locate these files.

It looks like a fix has already been made (see this thread) but until it is released you can get these files directly from vim’s SVN repo: diff.vim and nosyntax.vim