If you run into the following error message when attempting an iptables-restore < my.rules:iptables-restore v1.4.8: no command specified
then the problem is that you have very likely just copied and pasted stuff into my.rules which has led to some dodgy line-breaks terminating blank lines in the file.
On a server I am working on right now, I installed a PHP application and attempted to run it. However, I ran into a "500 Internal Server Error". Upon further investigation by checking the logs, I found the following errors in the Apache error log:
I currently work with an SVN checkout which tracks a separate GIT checkout (for reasons of managerial short-sightedness). When I update my git checkout, I find that the SVN checkout does not like the fact that files deleted by the git update have effectively been removed from the SVN checkout without the use of svn rm. Consequently, it is impossible to commit the updated checkout into the SVN repository.
Earlier today, I found myself working with an SVN checkout. As it happened, the repository that the files had been checked out from was no longer responding and upon enquiry, I found out that it had been moved to a different URL. Now, while I could have just as easily created an entirely different checkout of the files using the new URL, considering the local customisations, I looked to see if I could just do something like a live switch. As I found out after some mucking about, switch is certainly the operative word.
On a new installation of GVim (in Windows 7), I ran into the following curious error whenever I tried to open a new document for editing:Vim E303: Unable to open swap file for "[No Name]", recovery impossible
According to friendly chap on IRC, this is caused by a temporary directory bug and that it can be fixed by adding the following directive to the _vimrc file:set directory=.,$TEMP
I work extensively on a Windows desktop. However, I do SSH into Linux servers often and I do so using PuTTY, a free and open source client. Everything works peachy. However, I recently had occasion to work extensively with some Unicode source data and I found that there were times when I thought that there were encoding issues with the data as they were not being displayed correctly on my screen.
It is often important, especially when dealing with databases and such, that files are stored in the correct character set. Failure to do so can result in illegible displays or even data corruption. Checking the character set of a file in Linux can be accomplished using the file command:
Jubal@Stranger:$ file migrate1.csv
migrate1.csv: Little-endian UTF-16 Unicode English text, with CRLF, LF line terminators
Jubal@Stranger:$ file migrate2.csvI'm not sure whether it was something I did, something that the Vim developers did, or an anomaly with the Windows 7 binary, but I could no longer see the line number and cursor position tracker in the bottom right of my interface. Looking at the menus, I could find nothing. I could turn on a line number prefix for each bleeding line, but this is not what I was after.
While trying to import a CSV file into MySQL today using the LOAD DATA INFILE command, I ran into the following situation:
mysql> LOAD DATA INFILE 'foo.csv' INTO TABLE bar FIELDS TERMINATED BY ',' ENCLOSED BY '#' LINES TERMINATED BY '\r' (a, b);
ERROR 29 (HY000): File 'foo.csv' not found (Errcode: 13)The file exists fine and the permissions are also kosher. After much gnashing of teeth and perusing of documentation, I found out that local file sources require the LOCAL keyword:
While importing some data today, I found myself having to convert the Roman numerals in the source to decimal. While there are scripts and tools available on the Internet to do so, a quicker way exists (or, at least, it did for my case). This solution is to simply import the data into Open Office Calc and use one of its native functions to do the conversion.
