Loading ...
Sorry, an error occurred while loading the content.
 

Re: New line not recognized

Expand Messages
  • Ben Fritz
    ... Here s a script to do the automatic reload for you (between DOS and Unix still unfortunately):
    Message 1 of 17 , Nov 16, 2012
      On Friday, November 16, 2012 10:11:34 AM UTC-6, Salman Halim wrote:
      >
      > Occasionally, I will get a file that was edited by both developers on DOS and Unix systems and their editors will quietly leave mixed newlines in there. I believe that Vim will open a file with mixed newlines as Unix (at least, this is what I see).
      >
      >
      > Basically, this counts the number of ^M characters and prints a message reporting the number of ^M characters (if any) and, if more than half the file contains them, suggests that the file might be DOS--otherwise, Unix. It also returns Vim script commands to fix the file format, but the autocommand doesn't use that. I put an arbitrary line limit of 10,000 lines so that the file opening process isn't slowed down too much by this check.
      >
      >
      > Admittedly, it's going to be have to refactored for Mac; also, that 'silent! execute' line contains a ^M (literal control-M) where there's a newline in the paste below.
      >

      Here's a script to do the automatic reload for you (between DOS and Unix still unfortunately):

      http://vim.wikia.com/wiki/Automatically_reload_files_with_mixed_line-endings_in_DOS_fileformat

      This version uses a timeout in milliseconds on a search() rather than limiting by number of lines.

      --
      You received this message from the "vim_use" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • jeroen
      ... Is there any reason why this is not the default on unix? Jeroen -- You received this message from the vim_use maillist. Do not top-post! Type your reply
      Message 2 of 17 , Nov 17, 2012
        On Friday, November 16, 2012 5:09:19 PM UTC+1, Marco wrote:
        > 2012-11-16 Ben Fritz:
        >
        >
        >
        > > On Friday, November 16, 2012 9:55:10 AM UTC-6, Marco wrote:
        >
        > > >
        >
        > > > > My Windows GVim opened the file exactly as you described: one long line.
        >
        > > > > However, by using ":e ++ff=mac" (again, no quotes) I was able to reload the
        >
        > > > > file correctly.
        >
        > > >
        >
        > > > Thanks a lot, that works. Can I automate this somehow, so that vim
        >
        > > > opens <CR> (mac) files automatically with the ff=mac setting?
        >
        > > >
        >
        > >
        >
        > > :help 'fileformats' (note the s at the end).
        >
        >
        >
        > Thanks
        >
        >
        >
        > set fileformats=unix,dos,mac
        >
        >
        >
        > did the trick.
        >
        Is there any reason why this is not the default on unix?

        Jeroen

        --
        You received this message from the "vim_use" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • Tony Mechelynck
        ... I m not sure, but on Unix (well, on Linux) I have occasionally met files which had a lot of lone carriage-returns and yet weren t Mac files. This happens
        Message 3 of 17 , Nov 17, 2012
          On 17/11/12 09:00, jeroen wrote:
          > On Friday, November 16, 2012 5:09:19 PM UTC+1, Marco wrote:
          >> 2012-11-16 Ben Fritz:
          >>
          >>
          >>
          >>> On Friday, November 16, 2012 9:55:10 AM UTC-6, Marco wrote:
          >>
          >>>>
          >>
          >>>>> My Windows GVim opened the file exactly as you described: one long line.
          >>
          >>>>> However, by using ":e ++ff=mac" (again, no quotes) I was able to reload the
          >>
          >>>>> file correctly.
          >>
          >>>>
          >>
          >>>> Thanks a lot, that works. Can I automate this somehow, so that vim
          >>
          >>>> opens <CR> (mac) files automatically with the ff=mac setting?
          >>
          >>>>
          >>
          >>>
          >>
          >>> :help 'fileformats' (note the s at the end).
          >>
          >>
          >>
          >> Thanks
          >>
          >>
          >>
          >> set fileformats=unix,dos,mac
          >>
          >>
          >>
          >> did the trick.
          >>
          > Is there any reason why this is not the default on unix?
          >
          > Jeroen
          >
          I'm not sure, but on Unix (well, on Linux) I have occasionally met files
          which had a lot of lone carriage-returns and yet weren't Mac files. This
          happens for instance when logging the stdout of a console program which
          displays a text-mode "progess bar" by using a CR to go to the left
          margin without advancing to the next line, in order to overwrite the
          line just written. ISTR that rsync used to do that (when I used it to
          keep my Vim source in sync before there was a Mercurial repository), and
          maybe Mercurial (with the "progress" extension), or the command-line
          "ftp" utility, do too. In that case you don't want to break the line at
          a lone CR but you may want to delete everything that precedes a CR which
          is not at the end of a line (CR at the end of a line, i.e. followed by a
          line-feed character, can be taken care of by reading the file with
          ++ff=dos).


          Best regards,
          Tony.
          --
          Bees are very busy souls
          They have no time for birth controls
          And that is why in times like these
          There are so many Sons of Bees.

          --
          You received this message from the "vim_use" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • Christian Brabandt
          Hi Tony! ... Sure enough, but that wouldn t have triggered Vim to set the fileformat to mac. As long there are some newlines in there, you would be safe.
          Message 4 of 17 , Nov 17, 2012
            Hi Tony!

            On Sa, 17 Nov 2012, Tony Mechelynck wrote:

            > On 17/11/12 09:00, jeroen wrote:
            > >On Friday, November 16, 2012 5:09:19 PM UTC+1, Marco wrote:
            > >>2012-11-16 Ben Fritz:
            > >>
            > >>
            > >>
            > >>>On Friday, November 16, 2012 9:55:10 AM UTC-6, Marco wrote:
            > >>
            > >>>>
            > >>
            > >>>>>My Windows GVim opened the file exactly as you described: one long line.
            > >>
            > >>>>>However, by using ":e ++ff=mac" (again, no quotes) I was able to reload the
            > >>
            > >>>>>file correctly.
            > >>
            > >>>>
            > >>
            > >>>>Thanks a lot, that works. Can I automate this somehow, so that vim
            > >>
            > >>>>opens <CR> (mac) files automatically with the ff=mac setting?
            > >>
            > >>>>
            > >>
            > >>>
            > >>
            > >>>:help 'fileformats' (note the s at the end).
            > >>
            > >>
            > >>
            > >>Thanks
            > >>
            > >>
            > >>
            > >> set fileformats=unix,dos,mac
            > >>
            > >>
            > >>
            > >>did the trick.
            > >>
            > >Is there any reason why this is not the default on unix?
            > >
            > >Jeroen
            > >
            > I'm not sure, but on Unix (well, on Linux) I have occasionally met
            > files which had a lot of lone carriage-returns and yet weren't Mac
            > files. This happens for instance when logging the stdout of a
            > console program which displays a text-mode "progess bar" by using a
            > CR to go to the left margin without advancing to the next line, in
            > order to overwrite the line just written. ISTR that rsync used to do
            > that (when I used it to keep my Vim source in sync before there was
            > a Mercurial repository), and maybe Mercurial (with the "progress"
            > extension), or the command-line "ftp" utility, do too. In that case
            > you don't want to break the line at a lone CR but you may want to
            > delete everything that precedes a CR which is not at the end of a
            > line (CR at the end of a line, i.e. followed by a line-feed
            > character, can be taken care of by reading the file with ++ff=dos).

            Sure enough, but that wouldn't have triggered Vim to set the fileformat
            to mac. As long there are some newlines in there, you would be safe.

            regards,
            Christian
            --

            --
            You received this message from the "vim_use" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • Tony Mechelynck
            ... Depending on how the logging is done, in the case I mentioned there could very well be quite a lot of s before the first , and, let s say,
            Message 5 of 17 , Nov 17, 2012
              On 17/11/12 14:34, Christian Brabandt wrote:
              > Hi Tony!
              >
              > On Sa, 17 Nov 2012, Tony Mechelynck wrote:
              >
              >> On 17/11/12 09:00, jeroen wrote:
              >>> On Friday, November 16, 2012 5:09:19 PM UTC+1, Marco wrote:
              >>>> 2012-11-16 Ben Fritz:
              >>>>
              >>>>
              >>>>
              >>>>> On Friday, November 16, 2012 9:55:10 AM UTC-6, Marco wrote:
              >>>>
              >>>>>>
              >>>>
              >>>>>>> My Windows GVim opened the file exactly as you described: one long line.
              >>>>
              >>>>>>> However, by using ":e ++ff=mac" (again, no quotes) I was able to reload the
              >>>>
              >>>>>>> file correctly.
              >>>>
              >>>>>>
              >>>>
              >>>>>> Thanks a lot, that works. Can I automate this somehow, so that vim
              >>>>
              >>>>>> opens <CR> (mac) files automatically with the ff=mac setting?
              >>>>
              >>>>>>
              >>>>
              >>>>>
              >>>>
              >>>>> :help 'fileformats' (note the s at the end).
              >>>>
              >>>>
              >>>>
              >>>> Thanks
              >>>>
              >>>>
              >>>>
              >>>> set fileformats=unix,dos,mac
              >>>>
              >>>>
              >>>>
              >>>> did the trick.
              >>>>
              >>> Is there any reason why this is not the default on unix?
              >>>
              >>> Jeroen
              >>>
              >> I'm not sure, but on Unix (well, on Linux) I have occasionally met
              >> files which had a lot of lone carriage-returns and yet weren't Mac
              >> files. This happens for instance when logging the stdout of a
              >> console program which displays a text-mode "progess bar" by using a
              >> CR to go to the left margin without advancing to the next line, in
              >> order to overwrite the line just written. ISTR that rsync used to do
              >> that (when I used it to keep my Vim source in sync before there was
              >> a Mercurial repository), and maybe Mercurial (with the "progress"
              >> extension), or the command-line "ftp" utility, do too. In that case
              >> you don't want to break the line at a lone CR but you may want to
              >> delete everything that precedes a CR which is not at the end of a
              >> line (CR at the end of a line, i.e. followed by a line-feed
              >> character, can be taken care of by reading the file with ++ff=dos).
              >
              > Sure enough, but that wouldn't have triggered Vim to set the fileformat
              > to mac. As long there are some newlines in there, you would be safe.
              >
              > regards,
              > Christian
              >

              Quoting options.txt lines 2905 sqq under 'fileformats':

              > This means that "mac" is only chosen when:
              > "unix" is not present or no <NL> is found in the file, and
              > "dos" is not present or no <CR><NL> is found in the file.
              > Except: if "unix" was chosen, but there is a <CR> before
              > the first <NL>, and there appear to be more <CR>s than <NL>s in
              > the first few lines, "mac" is used.

              Depending on how the logging is done, in the case I mentioned there
              could very well be quite a lot of <CR>s before the first <NL>, and,
              let's say, something like fifty <CR>s before the fifth <NL>.


              Best regards,
              Tony.
              --
              UNIX was half a billion (500000000) seconds old on
              Tue Nov 5 00:53:20 1985 GMT (measuring since the time(2) epoch).
              -- Andy Tannenbaum

              --
              You received this message from the "vim_use" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            • Christian Brabandt
              Hi Tony! ... It is more likely, the file is really in MAC format rather than some obscure logfile. regards, Christian -- Es gibt problematische Naturen, die
              Message 6 of 17 , Nov 17, 2012
                Hi Tony!

                On Sa, 17 Nov 2012, Tony Mechelynck wrote:

                > Depending on how the logging is done, in the case I mentioned there
                > could very well be quite a lot of <CR>s before the first <NL>, and,
                > let's say, something like fifty <CR>s before the fifth <NL>.

                It is more likely, the file is really in MAC format rather than some
                obscure logfile.

                regards,
                Christian
                --
                Es gibt problematische Naturen, die keiner Lage gewachsen sind,
                in der sie sich befinden, und denen keine genugtut. Daraus entsteht
                der ungeheure Widerstreit, der das Leben ohne Genuss verzehrt.
                -- Goethe, Maximen und Reflektionen, Nr. 278

                --
                You received this message from the "vim_use" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
              • stosss
                ... Just adding a comment. A couple weeks ago I had 4 files that I created on my Linux system and did not move them or share them and some how they were
                Message 7 of 17 , Nov 17, 2012
                  On Sat, Nov 17, 2012 at 11:39 AM, Christian Brabandt <cblists@...> wrote:
                  > Hi Tony!
                  >
                  > On Sa, 17 Nov 2012, Tony Mechelynck wrote:
                  >
                  >> Depending on how the logging is done, in the case I mentioned there
                  >> could very well be quite a lot of <CR>s before the first <NL>, and,
                  >> let's say, something like fifty <CR>s before the fifth <NL>.
                  >
                  > It is more likely, the file is really in MAC format rather than some
                  > obscure logfile.
                  >

                  Just adding a comment.

                  A couple weeks ago I had 4 files that I created on my Linux system and
                  did not move them or share them and some how they were showing a ^M
                  when I was doing a grep and sed search and replace from the shell. So
                  it must be possible to create that condition on Linux but I have no
                  idea how it happened but the files are no longer showing that
                  condition.

                  --
                  You received this message from the "vim_use" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php
                • Ben Fritz
                  ... The problem wasn t showing a ^M , that s pretty common. The problem was that EVERY line was terminated ONLY by a ^M and there were NO linefeed characters
                  Message 8 of 17 , Nov 18, 2012
                    On Saturday, November 17, 2012 10:46:01 PM UTC-6, stosss wrote:
                    >
                    >
                    > A couple weeks ago I had 4 files that I created on my Linux system and
                    >
                    > did not move them or share them and some how they were showing a ^M
                    >
                    > when I was doing a grep and sed search and replace from the shell.

                    The problem wasn't "showing a ^M", that's pretty common. The problem was that EVERY line was terminated ONLY by a ^M and there were NO linefeed characters in the file at all, so the file was showing as one long line with a bunch of ^M characters.

                    --
                    You received this message from the "vim_use" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php
                  • stosss
                    ... Okay :-) thanks. I didn t realize that happens a lot with the ^M . They showed up again in a file last night but not the continuous single line. Then they
                    Message 9 of 17 , Nov 18, 2012
                      On Sun, Nov 18, 2012 at 8:50 AM, Ben Fritz <fritzophrenic@...> wrote:
                      > On Saturday, November 17, 2012 10:46:01 PM UTC-6, stosss wrote:
                      >>
                      >>
                      >> A couple weeks ago I had 4 files that I created on my Linux system and
                      >>
                      >> did not move them or share them and some how they were showing a ^M
                      >>
                      >> when I was doing a grep and sed search and replace from the shell.
                      >
                      > The problem wasn't "showing a ^M", that's pretty common. The problem was that EVERY line was terminated ONLY by a ^M and there were NO linefeed characters in the file at all, so the file was showing as one long line with a bunch of ^M characters.
                      >

                      Okay :-) thanks. I didn't realize that happens a lot with the "^M".
                      They showed up again in a file last night but not the continuous
                      single line. Then they were gone without me doing anything. I have
                      never actually seen them when opening the actual file. Only when doing
                      a shell command that out puts to the screen. Like grep, cat, head,
                      tail etc. I have also never seen them in a file created when using a
                      redirect away from the screen.

                      --
                      You received this message from the "vim_use" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php
                    Your message has been successfully submitted and would be delivered to recipients shortly.