Suppose you make a strace of a process (e.g. ls -lvim --help which outputs the standard vim commandline help) using the following command

strace -f -s 4095 vim --help 2>$HOME/tracefile.txt

This creates a very large file with all system calls the process did during it's execution. To now find the file accesses in this tracefile you maybe would open this file in vim and then would naïvly search e.g. for the string ] open ( to see, which files where opened. Vim search hightlighting would show you all open statements, but you would have to read the file yourself to find the corresponding close statement. Works, but gets very strenously if there are a lot of open-calls.

Now, with the following search-pattern in vim (using search highlighting) you will find the whole block in the trace file; from the beginning open to the ending close-call wonderfully highlighted for a quick overview. (Enter this after pressing / in command-mode.)

] open(.* = \(\d*\)\_.\{-}] close(\1)

This pattern uses several new features I never really used before (Which is funny, as I tend to use regular expressions a lot). An example of the block this pattern finds is

] open("/usr/share/tcltk/tcl8.4/encoding/iso8859-1.enc", O_RDONLY|O_LARGEFILE) = 5
[pid 14780] fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
[pid 14780] ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfb1bfa8) = -1 ENOTTY (Inappropriate ioctl for device)
[pid 14780] read(5, "# Encoding file: iso8859-1, single-byte...", 4096) = 1094
[pid 14780] read(5, "", 4096)           = 0
[pid 14780] close(5)

EDIT: As a reader remarked, my first example in this blog entry with ls -l is not very good. strace -f -s 4095 ls -l 2>$HOME/tracefile.txt does not work with the given pattern, as no pid-information is output (it seems strace only outputs pid-information, if the process is multithreaded.). So without the pid-information, the pattern should look like this: ^open(.* = \(\d*\)\_.\{-}] close(\1). In this case only open and close calls on the main-thread are found. If you omit the first ^ in the pattern, the search should still work although it might get mixed up with the string open inside string-outputs from strace. In summary this blog entry was created way to fast without proper testing. Sorry for this. Hopefully the information in this entry still is of some use.

backreferencing

As you can see, the open call returns a handler id which is used to also close the access again. Therefore we use \(\d*\) to mark the first occurrence of the handler at the end of the line and backreference it at the end with \1. (Using \2, \3 etc. you also could backreference more than one \(\) pattern.

multi line search

Normal you only search for patterns which can be found on one line. Here we have read over line endings. This is done by using \_. which is the same as . but also takes in account line endings.

greedy search

I you use the multiplier * to match more then one character, the longest string matching the atom will be found. For example with the string cabcabcabcab searching for c.*b will result in the full string found, as it starts with c and ends with b. If you only want to get cab you have to do a greedy search, which is done by using the multiplier \{-}. So doing c.\{-}b will result in finding only cab.

addendum

Be aware that this will not really work good, if the open and close statements are entangled. But it seems to work most of the time.

If you want to learn more about regular expressions in vim just enter :help regular-expression or :help pattern inside a vim-session.

Regular expressions can and should also be using in perl, javascript, sed, php, etc. They are very powerful constructs. Unfortunately every system seems to have its own dialect of regular expressions. But if you know the basic structure of regular expressions you learn to cope with the differences really fast.

Unfortunately I did not find a tool to exactly tell me which application is currently writing to which file on the harddrive. But a least with the tool iotop I was able to find out, which application is writing to the hard disc at all. Under ubunto or debian install this simply by invoking

apt-get install iotop

Like top this python-application continuously outputs the current processes which are using the hard drive. But you have to be very attentive to catch all applications while this tool is running. To get a better overview of all hard drive activity call the tool with the following parameters:

sudo iotop -qqqtaPob

This parameters put iotop into a mode where it outputs something like a logfile to the screen. Just let this run in the background, do something on your computer and then check, what tools where using the harddrive. Take a look in the man-pages of iotop to get the meaning of the parameters.

Now I am looking for a tool to really see to which files a running process currently is writing to. Some tests with strace -f -e trace=file -p PID where promising but failed if the running process opens the file only once at startup.

Anyone any ideas how to really see what and where a process writes something to the hard drive?

Zunächst mal Eclim. Das ist ein Plugin sowohl für Vim als auch für Eclipse. Wer normalerweise mit Vim arbeitet, wird Eclipse als ein furchtbar langsames Ungetüm empfinden. Um einige der Funktionalitäten von Eclipse in Vim zu verwenden, aber dabei trotzdem schnell und flexibel zu arbeiten, der wird dieses Plugin mögen. Für Projekte mit tiefer Baumstruktur lohnt es sich definitiv. Auch die automatische Syntax-Pruefung bei Speicherung von php-Dateien ist sehr praktisch. Auch ich habe allerdings die ganze tiefe von Eclim noch nicht durchschaut. Dieses kleine Plugin ist sehr mächtig und der Programmierer Eric Van Dewoestine ist in seiner Mailingliste wahnsinnig schnell beim Beantworten von Fragen.

Ein kleiner Tipp von mir (selbst erst in der Mailing-Liste gelernt). Mit den folgenden beiden Einstellungen, sieht Vim schon beim Start in einem Eclipse-Projekt-Verzeichnis ein bisschen wie eine IDE aus. :)

" ProjectTree immer darstellen.
let g:EclimProjectTreeAutoOpen = 1
let g:EclimProjectTreeExpandPathOnOpen = 1

Die zweite Seite ist eine fantastische Fundgrube an Tools und Ideen für Vim, um hier wirklich IDE-Funktionalität zu erhalten. Vor allem der Tipp mit xdebug und dem Vim-Debugger-Plugin, ist genial. Nur ein bisschen Konfiguration und man kann bequem php-Applikationen debuggen. Und das beste dabei, unter Debian sind die meisten Sachen nur ein apt-get install weiter entfernt.

Das ganze mag einigen nicht neu vorkommen, aber ich war doch überrascht über die Möglichkeiten, die hier noch zu finden sind. Ich mag Vim einfach!

Welcome to Eclim - eclim (eclipse + vim)

VIM an a PHP IDE - Thomas Koch

Ansonsten hier noch ein Link zu einem neuen Blog von einem guten alten Freund. Wobei ich sagen muss, dass die Seite ziemlich dunkel ist (von der Farbe her) und sehr kleine Schrift verwendet (oder ich werde alt. :) )

NanoBlogger

w7x - So gehts auch…

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE=de_DE@euro
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

The same problem manifested in perl:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_PAPER = "de_DE.UTF-8",
        LC_CTYPE = "de_DE@euro",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

First I thought it was a problem on the remote server. Googeling around I found a lot of users with the same problem, but not really a solution how to fix it correctly and what the problem is in the first place.

In the end some hints brought me to the solution: Debian in its default configuration allows ssh to set some environment-variables on the remote server. This is configured in /etc/ssh/ssh_config with the line SendEnv LANG LC_*. I think debian went this route to allow umlauts and other special chars to be possible in a ssh-session. Now, if the locale-setting on your local machine is not installed on the remote-system you get the aforementioned error-messages when you ssh to the remote server.

So, to get rid of this problem (which normally is only cosmetic) you have two possiblities:

• Don't send the environment locales from your locale machine to the remote machine. I took this way by just commenting out the line SendEnv LANG LC_* in /etc/ssh/ssh_config as I don't see any reason to set it on the remote system.
• Or install the locale which you use on your local system on the remote system.

I hope this helps some people coping with this problem and searching for an answer.

Volksbegehren Nichtraucherschutz Bayern

Winterreifen für Renault Clio

Derek Wyatt's videos on Vimeo

welcome home : vim online

commandlinefu.com

Jerris Shop

QR-Codes heissen diese 2D-Barcodes, die man mit den meisten neuen Handys und dem IPhone abfotografieren und lesen kann. Wer selbst einen solchen 2D-Barcode erstellen will, kann dies auf der folgenden Seite tun:

QR-Code Generator