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

Re: New line not recognized

Expand Messages
  • 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 1 of 17 , Nov 17, 2012
    • 0 Attachment
      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 2 of 17 , Nov 17, 2012
      • 0 Attachment
        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 3 of 17 , Nov 17, 2012
        • 0 Attachment
          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 4 of 17 , Nov 17, 2012
          • 0 Attachment
            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 5 of 17 , Nov 17, 2012
            • 0 Attachment
              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 6 of 17 , Nov 17, 2012
              • 0 Attachment
                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 7 of 17 , Nov 18, 2012
                • 0 Attachment
                  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 8 of 17 , Nov 18, 2012
                  • 0 Attachment
                    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.