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!
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.
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. :)
Und wieder mal ein interessanter Artikel zu einem der Tools, die ich benutze. Diesmal erneut eine Einführung zu remind.
Lange nicht mehr hier gepostet. Aber im Moment ist es Stressig. Sowohl in der Arbeit, als auch natürlich beim WoW-Spielen.
Beim Lesen der Vim-Mailing-Liste bin ich mal wieder auf eine interessante Seite gestoßen. Amir beschreibt hier seine vim-Umgebung und gibt Tips, wie man vim noch effizienter benutzen kann. Bestimmt nicht jedermanns Sache, aber denoch sehr viele interessante Ideen enthalten!
Ich habe es übrigens tatsächlich gemacht. Ich habe mir World of Warcrafts gekauft und bin jetzt echter Held in dieser simulierten Welt. Ich fürchte, man merkt es an der Menge von Einträgen in meinem Blog. Aber keine Sorge. Ich werde versuchen dennoch bald wieder ein paar Einträge zu machen.
Meine letzte Entdeckung an der Konsole ist übrigens das Programm cdargs.
Unter Debian schnell als Paket zu installieren. Danach noch die folgende Zeile in die .bashrceintragen:
source /usr/share/doc/cdargs/examples/cdargs-bash.sh
Dann neu einloggen, damit die .bashrcneu gelesen wird. Jetzt hat man diverse neue Befehle, mit denen man Verzeichnisse wechseln kann. Aber was ist daran so revolutionär? Verzeichnisse wechseln kann man auch mit cd!
Nun, der Witz ist, dass man nun Verzeichnisse sozusagen bookmarken kann. Wenn man also öfters mal in ein sehr tiefes Verzeichnis springen muss, dann kann man das folgende machen, um den Weg beim nächsten Mal wesentlich zu verkürzen.
# cd /wirklich/sehr/tiefe/verzeichnis/struktur # mark einfachername
Das aktuelle Verzeichnis wurde jetzt mit dem Namen einfachernameverbunden. Wenn man nun wieder in dieses Verzeichnis springen will, dann kann man das einfach, indem man das folgende an der Konsole eintippt:
# cv einfachername
cvist eine function, die cdargs aufruft, den Namen auflöst und in das entsprechende Verzeichnis springt. Sicher kann man diese Funktionalität auch mit symbolischen Links auf der Festplatte machen. cdargs erscheint mir aber aufgeräumter und einfacher.
Desweiteren unterstützt cdargs die Tab-Completion der Bash und man kann den Verzeichnisbaum auch über eine NCurses-Oberfläche erforschen.
Jetzt arbeite ich schon so lange mit vimund finde doch immer wieder etwas neues, was ich noch nicht gewusst habe. Es handelt sich um den Befehl :Ex, den ich bisher noch nicht kannte. Auf diesen Befehl gebracht hat mit der folgende Artikel, den Nick Lo auf der vim-Mailinglist gepostet hat:
Ingredients » Nick's Notepad » Blog Archive » File browsing in Vim
Danke Nick! :)