CHOMP VS. CHOP

radagast has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
RE: CHOMP VS. CHOP by Jonathan (Curate) on Aug 02, 2000 at 13:22 UTC
Are you connecting to a Unix server from a windoze client? Domestos has a two characters at the end of a line. A line feed and a carriage return. Unix has just the line feed. I wrote a win32/unix client server app recently and didn't have any problems with the conversion. I wouldn't use a chop instead of chomp here but I doubt the carriage return is a random event. I've tried to re-create the problem with the following code on NT and Solaris but I'm afraid it works fine for me? Server code on a unix box `#!/usr/local/bin/perl use IO::Socket; print "Waiting...\n"; $socket = IO::Socket::INET->new(LocalPort => 4321, Proto => 'udp'); $socket->recv($text,128); chomp $text; print "Got this message: >${text}<\n"; close $socket;` [download] And the client `#!/usr/local/bin/perl use IO::Socket; $x="my string ends here\n"; $sock = new IO::Socket::INET( PeerAddr => 'machine_name', PeerPort => 4321, Proto => 'udp'); $sock->send($x);` [download] Produces; Got this message: >my string ends here< In my experience some ftp/udp/tcp clients leave the ^M on and some don't. If you have it check out Russ's node Removing ^M	[reply] [d/l] [select]
Re: CHOMP VS. CHOP by atl (Pilgrim) on Aug 02, 2000 at 12:58 UTC
Welcome to the world of cross platform programming! :-) I don't know if there is a elegant solution to this, but since `chop` will always take away the last character I don't like it very much. I'd suggest to do something along this: `# ... read into $line chomp $line; $line =~ s/\r$//; # ... carry on` [download] That should work for any win-unix-combo (client as well as server; code is untestet, though, and might contain some lurking errors ;) ) Cheers ... Andreas Update: Think before submitting ... the line about "any win-unix-combo" is BS, I'm sorry. This will work if your client (executing this script) is unix and the server (where you read from) is win or unix.	[reply] [d/l] [select]
RE: CHOMP VS. CHOP by pschoonveld (Pilgrim) on Aug 02, 2000 at 15:16 UTC
chomp, by definition, removes the contents of $/ from the end of a string. Perhaps, if you know that your client will be windows, you should set $/ to \n\r (or is it \r\n, I can never remember). What it comes down to is that windows uses a \r\n combination as it's end of lines, and *nix appropriately uses \n. The sketchy, but easy way to handle this is to do a regex replacement (s/to replace/replacement/). But, that could cripple you should you want multi line data to stick around. My preference would be to remove any instance of \r (your ^M) and chomp when necesary.	[reply]
RE: RE: CHOMP VS. CHOP by amelinda (Friar) on Oct 11, 2000 at 22:33 UTC
It's \r\n, fo' sho'. Think about it - CR then LF makes up the mystical CRLF in DOSland, and you only need LF in UNIXland. Aren't mnemonics great?	[reply]
Re: CHOMP VS. CHOP by amelinda (Friar) on Oct 13, 2000 at 01:26 UTC
I just recently had a hairy issue where someone, in their CGI script, had a `chop; chop; $_ = "$_\n";` [download] which made file uploads from browsers in Windows DTRT, but totally broke my UNIX file-upload thingy. Part of the solution involved changing those three lines to read: `chomp; chomp; $_ = "$_\n";` [download] You might try that here.	[reply] [d/l] [select]
RE: CHOMP VS. CHOP by lindex (Friar) on Aug 02, 2000 at 20:41 UTC
When ever I have had to deal with those pesky ^M's I have found the line `s/^M/\n/g;` is always nice :) lindex `/**************************/ jason@gost.net, wh@ckz.org http://jason.gost.net /***************************/` [download]	[reply] [d/l] [select]
RE: RE: CHOMP VS. CHOP by nuance (Hermit) on Aug 02, 2000 at 20:48 UTC
That would change all your ^M^J into ^J^J i.e. every newline has just become two newlines. Fine if that's what you're trying to achieve, if not surely `s/^M//g;` [download] would be better. *Nuance*	[reply] [d/l]


P is for Practical
	PerlMonks