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

Hi all,

I'm seeing something very unusual. Here's the scenario: I've wrote a script to read 2 files, and write stuff from them to the 3rd file

I found out that if I copied the lines from the files completely without editing them, it works fine, the ^M doesnt appear at the back of the new file, however, if I add a "\n" at one or 2 lines for the new file, the ^M appears at the back of each line in the new file. Is there something that I'm not doing right?

When I did

print NEW_FILE "`$Lines_from_old_files`;";

the ^M doesnt appear anywhere. But if I did

print NEW_FILE "`$Lines_from_old_files`;\n";

the ^M appears everywhere

Replies are listed 'Best First'.
Re: Bad interpreters coming out
by GrandFather (Saint) on Apr 06, 2011 at 08:12 UTC

    How was the old file generated. What OS are you using. How are you "seeing" the ^M characters? How do you open the input file? How do you open the output file?

    True laziness is hard work
[reply]

      Old files are .pl and .sh, the perl script created by a website which sends the .pl into the debian based system through ssh, the .sh file is generated by the system itself

      the OS is a debian based OS

      The ^M characters are like:

      `cp /tmp/unzip/*.cfg /tmp/unzip/seed`;^M

      [download]

      That is just one line of the new file, ^M is all over the file everywhere

      I read the file using

       open FH, "< $filename" or die "smth smth";

      I wrote to the file using

       open NF, "> $filename2" or die "blabla";

      I opened it using vim

[reply]
[d/l]
[select]

        It seems exceedingly unlikely that a Perl script running on a *nix system using standard Perl IO would add ^M characters to files. It is much more likely that the characters exist in the original files and that those files were generated or edited on a Windows system.

        A simple test would be to create a fourth file that you write a few test lines to, then check that file for extra ^M characters. If they exist there is something weird with your build of Perl. If they don't exist then either the characters are in the source files, or you have managed to get your write file handle into a strange :crlf layer like state.

        True laziness is hard work
[reply]
Re: Bad interpreters coming out
by elef (Friar) on Apr 06, 2011 at 10:03 UTC
    I don't get the thread title at all. How is this a case of "bad interpreters coming out"? What "interpreters"? Where do they come out? From the title, I thought this was a thread about misbehaving perl interpreters.

    This is a case of CRLF line endings being generated when you expected LF (the extra character is CR, not ^M. ^M is just vim's representation of a CR character).
[reply]
      I wondered that as well. My guess was that some shells report "bad interpreter" (or something similar) when a ^M (\r) appends the program path on the #! line.

      dos2unix, or s/\r//, would be my solution.
[reply]
Re: Bad interpreters coming out
by anonymized user 468275 (Curate) on Apr 06, 2011 at 11:38 UTC
    Unix uses line feed ^J, Windows carriage return ^M for carriage control. Files from Windows can be converted using dos2unix or unix2dos (on most unix systems) when transferring in reverse. ascii mode ftp will also perform carriage control translation implicitly.

    Without any such translation, unix, when seeing both characters will pick the LF as the carriage control and render the ^M separately. Some unix programs can interpret a single ^M as carriage control but the addition of "\n" (^J on unix) will force it to pick only the ^J for carriage control and to render the ^M.

    One world, one people

[reply]

Back to Seekers of Perl Wisdom