This is more or less a followup to my last blog entry. Still trying to find out about which application is using my hard drive. I experimented some more with strace and learned something about vim search patterns. :)
Suppose you make a strace of a process (e.g.
ls -l
vim --helpwhich 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 -lis not very good. strace -f -s 4095 ls -l 2>$HOME/tracefile.txtdoes 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 openinside 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.
As you can see, the opencall returns a handler id which is used to also closethe 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, \3etc. you also could backreference more than one \(\)pattern.
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.
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 cabcabcabcabsearching for c.*bwill result in the full string found, as it starts with cand ends with b. If you only want to get cabyou have to do a greedy search, which is done by using the multiplier \{-}. So doing c.\{-}bwill result in finding only cab.
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-expressionor :help patterninside 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.
Ever wondered which application right now is writing to the hard drive. Currenlty trying to minimize the hard drive usage on my laptop and tried to answer this exact question.
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 iotopI 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 topthis 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 iotopto 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 PIDwhere 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?
Da ich gerade wieder sehr stark am PHP-Programmieren bin, war ich wieder etwas im Netz unterwegs um Tools und Tipps zur einfacheren Programmierung von tief verschachteltem OOP-PHP-Code zu finden. Dabei habe ich zwei sehr interessante Seiten gefunden.
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 Seiteist 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 installweiter 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!
NanoBloggerhat sich inzwischen ziemlich weiterentwickelt, was mich gezwungen hat, einige Templates neu zu erstellen bzw. anzupassen. Jetzt sollten eigentlich alle Seiten in diesem Blog (auch im Archiv die Jahresüberblicke) wieder korrekt dargestellt werden. Wenn noch jemand eine Seite auf meinem Blog findet, die nicht korrekt aussieht oder falsch verlinkt ist, dann bitte doch bei mir melden!
Ansonsten hier noch ein Link zu einem neuen Blogvon 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. :) )
I recently had the problem, that I got the following error when I connection to a new debian-server via ssh and then called locale:
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_configwith 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:
I hope this helps some people coping with this problem and searching for an answer.
Hier ein Link für alle Nichtraucher und die, die es werden wollen. Ein Volksbegehren zum konsequenten Nichtraucherschutz. Es werden 950 tausend Unterschriften benötigt. Sollte jeder mal durchlesen und selbst drüber nachdenken. Start der Unterschriftenaktion am 19. November 2009.
Jetzt schlägts Dreizehn. Nun bin ich schon so lange im Internet unterwegs, spiele mit allen möglichen Sachen rum und versuche soweit möglich am Ball zu bleiben. Und doch habe ich erst jetzt die Möglichkeit gefunden, mal einen Artikel bei Ebay zu versteigern. Und zwar geht es um die Winterreifen des Renault Clio, den ich mal gefahren bin. Die liegen nun doch schon seit einem Jahr im Keller rum und verbrauchen dort nur Platz. Wer also welche braucht, hier ist der Link: :)
Wieder mal nur ein kleiner Link, gefunden im weiten Netz, zum Thema , dem VIMbesten Editor der Welt. Derek Wyatt hat sich die Mühe gemacht, diverse Editierkonzepte in VIM in kleinen Videotutorials zu erklären. Sehr schön gemacht und auch ich habe wieder mal etwas gelernt. Man hört nie auf damit. Insbesondere für Anfänger sind diese Videos eine gute Hilfe, da auch einfachere Dinge in VIM erklärt werden. Alle Tutorials sind in englischer Sprache.
Eine kleine aber feine Seite, die ich erst vor kurzem gefunden habe. Hier ist gerade ein Wust an Inspiration versammelt, was das Scripting angeht. Wer viel und oft etwas auf der Console erledigt, sollte hier mal einen Blick drauf werfen. Vieles ist bestimmt bekannt, aber die eine oder andere Idee kann man abgreifen. :)
Eigentlich naheliegend, die Idee. Aber trotzdem ganz nett. Wer eine nette Botschaft weitergeben möchte, holt sich das T-Shirt "Jemand mag dich!". Und wer sinnloserweise für meine Website Werbung machen will, der hole sich das www.jerri.de-Fan-T-Shirt. :)
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: