12 replies to this topic

[katherholt]

When I did the first installation, I could not read any fonts in the manager program, I looked at the /manager/includes/lang/english.inc.php - and it was all run together. I make line breaks at the semi-colons, overwrote the original and it works great now. Attached is a text file if anyone else should have this problem. I'm using IE7 - on a PC.

Edited by Ralph, 06 May 2008 - 06:13 PM.
The attached file contained additional errors...

[Dean]

Which archive did you use? the .zip or the .tar.gz? I'm using the zip without issue :/

[katherholt]

Which archive did you use? the .zip or the .tar.gz? I'm using the zip without issue :/

The '.zip' file (not from source forge). Well, I went back to my original downloaded zipped file and it was OK, it must have happened during the FTP process. The setting is on 'passive' mode.

[Ralph]

Very odd... I just unzipped onto my laptop and had different issues in different editors... In one editor all but the first $ were missing but the line breaks were present... In another editor the line breaks were missing... I yet another I had block characters where the line breaks should be...

I think it may stem from zipping under Linux... Now I'm curious as to whether this is the only file exhibiting this problem... I'll investigate further... We've been using similar zip's for weeks to do testing without issue...

Karen, did you unzip using XP or Vista...???

EDIT: After further investigation it appears that this is a CR/LF issue... I need to see if I have a utility kicking around that can do a recursive repair to the entire code base... Some editors are more forgiving than others as far as line breaks are concerned... The three variations are:

DOS format (CR/LF)
*nix format (LF)
Mac format (CR)
CR = Carriage Return
LF = Line Feed

[Ralph]

It appears that the problem has to do with, umm, Dean using a Mac to edit files and not setting the EOL setting to Unix or DOS/Windows... All files set to Unix will work fine in a Windows enviroment and Windows files will work fine in a Unix environment... Mac is the odd man out... Unix will compensate for the Mac format but Windows won't...

Dean, if you can rmemeber which files you edited recently, please let me know... My one global change feature isn't working as well as I had expected...

[katherholt]

It appears that the problem has to do with, umm, Dean using a Mac to edit files and not setting the EOL setting to Unix or DOS/Windows... All files set to Unix will work fine in a Windows enviroment and Windows files will work fine in a Unix environment... Mac is the odd man out... Unix will compensate for the Mac format but Windows won't...

Dean, if you can rmemeber which files you edited recently, please let me know... My one global change feature isn't working as well as I had expected...

I had the same experience last night on another installation with the english language file - that seems to be the only problem I've run into. (Windows XP- PC, Unix FTP (passive mode), IE7)

I worked several hours inputting data into an updated installation and I must say the editor is great and everything runs much smoother and faster. I appreciate all the hard work that has gone into this project. It has made my job easier and I love new things! The colors are great and the tutorials on the new installation are very well written.

[DeepWoods]

It appears that the problem has to do with, umm, Dean using a Mac to edit files and not setting the EOL setting to Unix or DOS/Windows... All files set to Unix will work fine in a Windows enviroment and Windows files will work fine in a Unix environment... Mac is the odd man out... Unix will compensate for the Mac format but Windows won't...

Dean, if you can rmemeber which files you edited recently, please let me know... My one global change feature isn't working as well as I had expected...

Would something like this help you?

#!/usr/bin/perl
$work_dir = '/var/www/html/somedir';
	
	
	# Standardize the format of the directory name
	die 'Path for work_dir must be absolute' unless $work_dir =~ /^\//;
	
	$work_dir =~ s/\/$//;		 # Delete trailing slash
	
	# Now get the content list for the directory.
	opendir(WDIR, $work_dir) or die "Couldn't read directory $work_dir";
	
	# Loop through this list looking for any "regular" file.
	while($entry = readdir(WDIR)) {
			next if $entry =~ /^\./;
			$entry = $work_dir . '/' . $entry;
	#	   system("echo $entry >> list.txt");
	#		system("unix2dos $entry") if -f $entry;
			system("dos2unix $entry") if -f $entry;
	}
	closedir(WDIR);

Edited by DeepWoods, 01 May 2008 - 01:48 PM.

[Ralph]

@DeepWoods

The major problem I am having is related to recursion... Well, maybe not... Actually, the problem is that neither dos2unix or unix2dos can perform mac2dos or mac2unix...

EDIT: Hmmm... It appears that dos2unix should do this conversion... I'll give it another go and see what happens...

[Dean]

Ummm last person to edit the language file wasn't me - I haven't edited files in a long time (SVN)
I know you've worked on the file since me, adding the new config options

Oh well....

[DeepWoods]

@DeepWoods

The major problem I am having is related to recursion... Well, maybe not... Actually, the problem is that neither dos2unix or unix2dos can perform mac2dos or mac2unix...

EDIT: Hmmm... It appears that dos2unix should do this conversion... I'll give it another go and see what happens...

See if this will work better for you?? I didn't even think about recursion the first go around.

#!/usr/bin/perl
 use strict;
 
 my($top_dir) = '/var/www/html/somedir';
 
 
 # Standardize the format of the directory name
 die 'Path for top_dir must be absolute' unless $top_dir =~ /^\//;
 
 $top_dir =~ s/\/$//;		 # Delete initial trailing slash
 
 digger($top_dir);
 
 
 sub digger($) {
   my($work_dir) = @_;
 
   # add a trailing slash
   $work_dir .= '/' if($work_dir !~ /\/$/);
 
   # loop through the files in the directory
   for my $entry (glob($work_dir.'*')) {
	 # if the file is a directory
	 if( -d $entry) {
	   # pass the directory back to itself for recursion
	   digger($entry);
	 } else {
	   # Do something to the file here.  
	   #  system("echo $entry >> list.txt");
	   #  system("unix2dos $entry") if -f $entry;
		 system("dos2unix $entry") if -f $entry;	  
	 }
   }
 }

[bogge]

I solved this by open the english.inc.php in notepad++ and choose Format -> Convert to Unix format.

Works for me!

[Ralph]

I solved this by open the english.inc.php in notepad++ and choose Format -> Convert to Unix format.

Works for me!

You are correct, bogge... There are editors for just about every OS that allow a files EOL format to be changed... The overall problem we were discussing here was a way to make global changes across the entire code base... I lost my old piece of code the last time I upgraded my server because to script was in the /bin directory... I have written a new script which recurses through the code base and changes all .txt, .php, .js, and .htm* files... It takes less than five seconds to fix the entire Etomite code base using this method with no need to search for problem files manually or wait for someone to report the problem...

[Ralph]

Here is the newest version of the english.inc.php language file for Prelude v1.0 whcih supercedes any previous versions posted here in the forums...

Attached Files

•  english.inc.php   73.75K   9 downloads