^M Character

alabonte

Hi,
I've been running into the ^M ,(CTRL+M), character a lot.

If I use PHP to edit a txt file, or call shell commands, it seems to stick ^M everywhere.

I can't figure out why, or how to stop it.

My current scenario, is trying to use the passwd function in linux, from PHP.

I've tried it with popen, and with proc_open...
<?
//open pipe
$pipe = popen("passwd","w");
//add new password, repeat it.
fputs($pipe,"abc123\n");
fputs($pipe,"abc123\n");

pclose($pipe);
?>

But my password gets set to ^M.

Any ideas?

andre @ performance technologies

ir4z0r

wasn't ^M the Windows-linebreak that appears as ^M by viewing
with a Linux/UNIX-System?

linux: \n
win: \n\r or \r\n (?)

correct me if I'm mistaken

alabonte

I think you are right.
the character definitely has something to do with DOS/Windows.

Cause if in some cases in the past, once PHP had added this character, VI'ing the file, would show DOS File, no-eol.

Any ideas, where is is coming from?

I'm running thttpd, PHP4.3.1 on Linux glibc.

andre @ performance technologies

Weedpacket

Hmm... sounds like there's a Windows machine involved somewhere in all this... that ^M is a "carriage return" character. Windows machines end lines in text files with "carriage return" "linefeed", while Unx systems just have the "linefeed". Read a Windows-written text file in a Unx system and you get a bunch of carriage returns.

There's a setting in php.ini regarding linebreaks, but it's intended more for Mac systems (that use a single "carriage return" to indicate end-of-line). Y'know, if PHP is saving text files in Mac format, then VI might misidentify it as "DOS File ['cos of the carriage returns], no-eol ['cos it doesn't find a linefeed]" - dunno if VI would recognise Mac text properly when it sees it.
They would have to be bloody different from everyone else, wouldn't they?