I work home with Dreamweaver cs5 on windows 7 and on work on windows xp Dreamweaver cs5.5
When i edit file home and open it from ftp on my work all spaces between lines of code double when i get home and open file there are additional space line added to each empty line why is this happening?
e.g.
if (true) {
test();
};
now looks like
if (true) {
test();
};
and this is everywhere.
Also sometimes rarely i open file and my php code does not have no new lines its all on the same big line like this.
if (true) { test(); };
Someone knows whats the problem here?
Maybe it will be not best answer, but...
Dreamweaver is wrong tool, use normal IDEs - PhpStorm or NetBeans.
Open the file
Click CTRL + F
Select "Current document" in "Find in" (You can also select the
folder if you have multiple files)
Search in "Source code"
Tick "Use regular expression"
Type "[\r\n]{2,}" (without quotes) in "Find"
Type "\n" (without quotes) in "Replace"
Press "Replace All"
This is something that does come up with Dreamweaver and it happens when you're on a Windows machine and you download a file from a Unix server.
There's a fairly easy fix to immediately get rid of the extra line breaks at least, if that's the current issue, and to prevent them in the future:
http://www.jaredstenquist.com/2009/02/13/removing-extra-linebreaks-and-spaces-in-dreamweaver/
When removing extra line breaks, it will remove all empty breaks so be sure this is what you want - you may have to create some manual breakss over again.
As for line breaks not appearing in rare cases, I suspect setting line break type to match your sever's as suggested in that article may address that issue as well.
Related
I'm attempting to write a bit of code that will allow users to change their expired Active Directory passwords via a PHP web interface. Due to limitations with PHP's ldap library's*, it seems the only way to do this is by generating an ldif and then passing this directly to ldapmodify.
The code I've come up with (minus the vars) is:
ldapmodify -H {$ad_server} -D '{$dn}' -w {$old} <<!
dn: {$dn}
changetype: modify
delete: unicodePwd
unicodePwd:: {$oldPassword}
-
add: unicodePwd
unicodePwd:: {$newPassword}
-
!
The code appears to work fine when I paste the generated code straight in to my console, but so far I've had no luck running it from PHP.
I originally tried passing the code to exec, only to get exitcode 247(which doesn't appear to be a real thing)
I then attempted to use proc_open instead, which provided the current error
ldapmodify: invalid format (line 5) entry: " ... "
So far as I can see the only thing on line 5 is a "-". So I'm a bit stuck as to what could be wrong.
P.S. I also read this post LDIF file error?? Invalid Format? which reported a similar problem, although assuming the encoding of the "-" character is the issue, I'm not sure what I can really do with it from with PHP (mb_string_encoding the whole string into utf-8 doesn't appear to have any effect)
This is also running on a solaris machine which may also be a factor.
*PHP is unable to perform two actions within a single command, somthing that is required in order to do a user password change in AD. (so far as I'm aware)
Edit: No sure why this is getting downvotes, but I'd be happy to be told I'm an idiot if I'm doing something patently stupid without noticing (so long as you point out what that is, as I've been stuck on this for a while now)
Thanks to some help from the #ldap channel on freenode it turns out I am indeed an idiot (especially considering that I've been poking and prodding this for most of the day).
It seems ldapmodify does not like it when an LDIF contains a windows new line characters after the "-" Switching line endings from windows to unix in sublime has fixed the problem for me*.
I have a PHP site and a cron job which runs to update the DB for the site. The cron reads a CSV file which is uploaded by a third party. Recently this cron job stopped working correctly. After some investigation, I've discovered that the problem is in the CSV file. The problem is that the new line character in the CSV has changed from the standard "\n" to the older ASCII "^M" and PHP doesn't seem to recognise this as a new line so instead of seeing the CSV as multiline, it is seeing it as one single line of info. I have only been able to see this difference in the Command Line text apps less and vim. Does anyone know of a way to get PHP to recognise these new line characters?
By way of an example, the incorrect CSV file looks similar to this in vim:
Heading 1,Heading 2,Heading 3,^MInfo 1-1,Info 1-2,Info 1-3,^MInfo 2-1,Info 2-2,Info 2-3,^M^M
Whereas the older (correct) version displays like this in vim:
Heading 1,Heading 2,Heading 3,
Info 1-1,Info 1-2,Info 1-3,
Info 2-1,Info 2-2.Info 2-3,
Set the auto_detect_line_endings option appropriately.
Can you not change your code to look for ^M or replace ^M with \n?
str_replace("^M", "\n", $input);
I'm trying to debug a plugin-bloated Wordpress installation; so I've added a very simple homebrew logger that records all the callbacks, which are basically listed in a single, ultimately 250+ row multidimensional array in Wordpress (I can't use print_r() because I need to catch them right before they are called).
My logger line is $logger->log("\t" . $callback . "\n");
The logger produces a dandy text file in normal situations, but at two points during this particular task it is adding something which causes my log file to no longer be encoded properly. Gedit (I'm on Ubuntu) won't open the file, claiming to not understand the encoding. In vim, the culprit corrupt callback (which I could not find in the debugger, looking at the array) is about in the middle and printed as ^#lambda_546 and at the end of file there's this cute guy ^M. The ^M and ^# are blue in my vim, which has no color theme set for .txt files. I don't know what it means.
I tried adding an is_string($callback) condition, but I get the same results.
Any ideas?
^# is a NUL character (\0) and ^M is a CR (\r). No idea why they're being generated though. You'd have to muck through the source and database to find out. geany should be able to open the file easily enough though.
Seems these cute guys are a result of your callback formatting for windows.
Mystery over. One of the callbacks was an anonymous function. Investigating the PHP create_function documentation, I saw that a commenter had noted that the created function has a name like so: chr(0) . lambda_n. Thanks PHP.
As for the \r. Well, that is more embarrassing. My logger reused some older code that I previously written which did end lines in \r\n.
I'm working with the PHP CLI on windows at the moment to write some small desktop command-line apps.
I wanted to know if and how it may be possible to:
Clear the screen (cls would be the normal command but exec() won't work with it)
Change the color, change the color of parts of the output (seen this in programs before)
Make the command line horizontally bigger - things quickly get unreadable
Is any of the above possible from inside a PHP script?
On Windows, in the standard CLI prompt, you cannot output in colour (as in the answer by Spudley).
You can change the size of the window as a user by right-clicking the command window's title bar and selecting Properties, then ammending values in the Layout tab. I do not think it is possible to ammend the width of the CLI within PHP.
You can check the width of the CLI window on Windows using the function I wrote here
See the PHP manual page for working with the commandline
To directly answer each of your bullet points:
There is a comment on that page which gives a function that can clear the screen. I'll quote it here for you:
<?php
function clearscreen($out = TRUE) {
$clearscreen = chr(27)."[H".chr(27)."[2J";
if ($out) print $clearscreen;
else return $clearscreen;
}
?>
There's also another comment which explains how to change the colours. Again, I'll quote it:
<?php
echo "\033[31m".$myvar; // red foreground
echo "\033[41m".$myvar; // red background
?>
and to reset:
<?php
echo "\033[0m";
?>
You should read through the rest of that page for a whole load more suggestions on how to manipulate the CLI.
The only part of your question that leave unanswered is the third bullet point. Sadly, I don't believe you'll be able to do this, and I don't think it's possible to horizontally resize the Windows command line window.
Hope that helps.
I created a small backup script with PHP, and from what I can remember, you can print backspace characters to remove content. Not really ideal though.
Just google'd it: http://www.php.net/manual/en/features.commandline.php#77142
As far as the third question goes, I suggest you witch the default command line to Console 2. It is a great replacement that not only lets you use any width you like (as long as it fits your screen), but also supports command history, tabs, and some UI sugar.
The provided code will not work under Windows because PHP under windows does something to the command window. I am not sure what PHP does but I wrote a simple Freebasic program with only two lines:
cls
end
I then compiled it and ran it under a regular command line window. It cleared the screen without any kind of a problem. I then did the following in PHP:
<?php
echo "This is a test\n";
system( "cls.exe" );
exec( "cls.exe" );
passthru( "cls.exe" );
?>
When I ran the program it did nothing more than just the "This is a test" line. Thus, there is some kind of suppression going on with PHP that looks for and stops any kind of escape sequence from occurring. Until this is fixed in PHP - you will never be able to do a cls, nor use curses, ncurses, or any other library. What has to be done is to integrate something like FreeBasic's windowing methods as some kind of a class (or maybe just a C set of routines) that will open a new window via THAT language's methodologies and use them to do the text window. Then all of the escape sequences will work. Until then - they won't.
What I find weird about this is that PHP was originally written in Perl and Perl will do ncurses on Windows without any problems. Perl will also allow all escape sequences to work. So there is just something being done on the Windows compile that is causing this problem.
I have a php function I wrote that will take a text file and list each line as its own row in a table.
The problem is the classic "works fine on my machine", but of course when I ask somebody else to generate the .txt file I am looking for, it keeps on reading in the whole file as 1 line. When I open it in my text editor, it looks just as how I would expect it with a new name on each line, but its the newline character or something throwing it off.
So far I have come to the conclusion it might have something to do with whatever text editor they are using on their Mac system.
Does this make sense? and is there any easy way to just detect this character that the text editor is recognizing as a new line and replace it with a standard one that php will recognize?
UPDATE: Adding the following line solved the issue.
ini_set('auto_detect_line_endings',true);
Function:
function displayTXTList($fileName) {
if(file_exists($fileName)) {
$file = fopen($fileName,'r');
while(!feof($file)) {
$name = fgets($file);
echo('<tr><td align="center">'.$name.'</td></tr>');
}
fclose($file);
} else {
echo('<tr><td align="center">placeholder</td></tr>');
}
}
This doesn't work for you?
http://us2.php.net/manual/en/filesystem.configuration.php#ini.auto-detect-line-endings
What's wrong with file()?
foreach (file($fileName) as $name) {
echo('<tr><td align="center">'.$name.'</td></tr>');
}
From the man page of fgets:
Note: If PHP is not properly recognizing the line endings when reading files either on or created by a Macintosh computer, enabling the auto_detect_line_endings run-time configuration option may help resolve the problem.
Also, have you tried the file function? It returns an array; each element in the array corresponds to a line in the file.
Edit: if you don't have access to the php.ini, what web server are you using? In Apache, you can change PHP settings using a .htaccess file. There is also the ini_set function which allows changing settings at runtime.
This is a classic case of the newline problem.
ASCII defines several different "newline" characters. The two specific ones we care about are ASCII 10 (line feed, LF) and 13 (carriage return, CR).
All Unix-based systems, including OS X, Linux, etc. will use LF as a newline. Mac OS Classic used CR just to be different, and Windows uses CR LF (that's right, two characters for a newline - see why no one likes Windows? Just kidding) as a newline.
Hence, text files from someone on a Mac (assuming it's a modern OS) would all have LF as their line ending. If you're trying to read them on Windows, and Windows expects CR LF, it won't find it. Now, it has already been mentioned that PHP has the ability to sort this mess out for you, but if you prefer, here's a memory-hogging solution:
$file = file_get_contents("filename");
$array = split("/\012\015?/", $file); # won't work for Mac Classic
Of course, you can do the same thing with file() (as has already been mentioned).