Archiv
Archiv IndexBlog-Status
Anzahl Kategorien: 19Anzahl Einträge: 139
Letzter Eintrag: 10.05.2022 23:21:12
Zuletzt geändert: 29.09.2023 01:13:09
RSS, Atom
Powered by
NanoBlogger 3.4.2
Vim als IDE
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 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!
NanoBlogger-Templates upgedated
NanoBlogger hat 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 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. :) )
Problem with locales on remote server via ssh
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_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.