Haben Sie Anregungen, Statements oder Kommentare? Dann schreiben Sie an redaktion@linux-magazin.de. Die Redaktion behält es sich vor, die Zuschriften und Leserbriefe zu kürzen. Sie veröffentlicht alle Beiträge mit Namen, sofern der Autor nicht ausdrücklich Anonymität wünscht.

Klug gesperrt

05/12, S. 90: Im Bash Bashing über das richtiges Locking fehlt ein Hinweis auf das Tool Flock. Meiner Erfahrung nach ist es die beste Lösung, wenn man sich nicht um das Aufräumen der Lockfiles kümmern möchte. Das geht, in dem der Programmierer die Skriptdatei selbst als Lockfile verwendet. Nach einem Absturz oder wenn der Prozess gekillt wurde, bleibt kein Lock zurück. Listing 1 zeigt eine Shellsitzung, die das verwendet.

01 server:~/tmp # cat test.sh
02 #!/bin/bash
03 sleep 5
04 echo fertig geschlafen
05 server:~/tmp # flock -w 1 -x test.sh -c ./test.sh || echo lock nicht bekommen &
06 [1] 62643
07 server:~/tmp # flock -w 1 -x test.sh -c ./test.sh || echo lock nicht bekommen &
08 [2] 62647
09 server:~/tmp # flock -w 1 -x test.sh -c ./test.sh || echo lock nicht bekommen &
10 [3] 62649
11 server:~/tmp # flock -w 1 -x test.sh -c ./test.sh || echo lock nicht bekommen &
12 [4] 62654
13 server:~/tmp # lock nicht bekommen
14 lock nicht bekommen
15 lock nicht bekommen
16 fertig geschlafen

Georg Höllrigl, per E-Mail

Stiefkind Locking

05/12, S. 90: Zum Bash Bashing 20: Die Themen Locking, Code-Serialisierung und Race Conditions werden meiner Meinung nach unterschätzt. Der Code des Tools »screen« beispielsweise geht das Locking falsch an (Listing 2), was als Debian Bug #653434 bekannt ist. Leider arbeitet offenbar niemand mehr an dem Projekt. Die Alternative Tmux, die das Linux-Magazin schon einmal vorgestellt hat, enthielt bis vor Kurzem ebenfalls einen Locking-Fehler. Hier sind die Maintainer allerdings sehr aktiv und haben ein Quelltext-Patch von mir rasch übernommen.

01 if (access(SockPath, F_OK)) {
02   if (mkdir(SockPath, 0700) == -1)
03     Panic(errno, "Cannot make directory '%s'", SockPath);
04 }

Tim Rühsen, per E-Mail

Perl prozedural und objektorientiert

05/12, S. 100: Lieber Michael Schilli, ich bewundere, wie Sie immer wieder neue Themen für Ihre Perl-Artikel finden und umsetzen. Schön fände ich, wenn Sie hin und wieder auch ein bisschen Methodik einbauen könnten.

Ich arbeite in einer kleinen Gruppe langjähriger Perl-Entwickler. Wir haben mit den Jahren vom rein prozeduralen Programmieren zum objektorientierten und wieder zurück gefunden. Das eine ist für das Zusammenarbeiten in der Gruppe nicht immer das Beste, aber wir kommen gut damit zurecht. Der objektorientierte Ansatz dagegen trägt immer so viel Ballast auf, dass wir ihn nach Jahren wieder abgetragen haben.

Wenn Sie als “Perlmeister” jedoch hin und wieder aufzeigen könnten, wie man Programme objektorientiert ansetzt und wie die Alternative im Prozeduralen aussieht, würden die Leser davon sicher profitieren. Als weiteres Thema wünsche ich mir Perl-Debugging. Ich bin mir gar nicht sicher, ob Sie sich dieses Themas schon einmal angenommen haben. Aber wenn, dann ist es wohl einige Zeit her.

Harald Jele, per E-Mail

Meine Artikel zum Debugging sind in der Tat schon eine Weile her. Anno 2005 habe ich einmal ein Tutorial für den Perl-Debugger geschrieben:https://www.linux-magazin.de/Heft-Abo/Ausgaben/2005/04/Humpeln-zur-Diagnose2 Etwas jünger, nämlich aus dem Jahr 2007, ist eine Abhandlung über das Debuggen von Perl mit dem GNU-Debugger GDB. Sie ist immer noch online unter der URLhttps://www.linux-magazin.de/Heft-Abo/Ausgaben/2007/01/Getriebeschadenzu finden. (Michael Schilli)