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

Linefeeds

Expand Messages
  • Axel Berger
    Were there any changes in the treatment of linefeeds to version 5.8? I have some files containing linefeeds ($0a) as well as correct newlines ($0d0a) and I
    Message 1 of 5 , Apr 4 9:55 AM
    • 0 Attachment
      Were there any changes in the treatment of linefeeds to version 5.8?

      I have some files containing linefeeds ($0a) as well as correct
      newlines ($0d0a) and I need to replace the linefeeds with something
      else. Loading such files in version 5.8 treats all these as full
      newlines and I can't get at the $0a or ^L any more. I remember this
      used to work once.
      What can I do?

      Thanks
      Axel
    • ebbtidalflats
      Hi Axel, One way to deal with this is to use a regular expression replace, to replace every occurrence of a linefeed NOT preceded by a Carriage return with
      Message 2 of 5 , Apr 5 6:02 AM
      • 0 Attachment
        Hi Axel,

        One way to deal with this is to use a regular expression replace,
        to replace every occurrence of a linefeed NOT preceded by a Carriage return with your choice of replacement string, i.e.:

        replace

        "([^\r])\n" with "$1X",

        where X is the character/string you want to replace the solitary linefeeds with.

        You could do this in a clip or the interactive search.


        This does NOT answer the question if NoteTab treats lf differently, or not. I have never knwoingly encountered MIXED end-of-lines in a file.


        Cheers,


        Eb

        --- In ntb-clips@yahoogroups.com, Axel Berger <Axel-Berger@...> wrote:
        >
        > Were there any changes in the treatment of linefeeds to version 5.8?
        >
        > I have some files containing linefeeds ($0a) as well as correct
        > newlines ($0d0a) and I need to replace the linefeeds with something
        > else. Loading such files in version 5.8 treats all these as full
        > newlines and I can't get at the $0a or ^L any more. I remember this
        > used to work once.
        > What can I do?
        >
        > Thanks
        > Axel
        >
      • Axel Berger
        ... Doesn t help. The file definitely contains 0a as well as the normal 0d0a, but after opening it in NoteTab all these are changed to 0d0a. A search for
        Message 3 of 5 , Apr 5 6:10 AM
        • 0 Attachment
          ebbtidalflats wrote:
          > One way to deal with this is to use a regular expression

          Doesn't help. The file definitely contains 0a as well as the normal
          0d0a, but after opening it in NoteTab all these are changed to 0d0a.
          A search for [^\r]\n finds nothing. This means just opening that
          file in NoteTab changes it and the very things I need to look for
          are no longer there. I may have to devise a complicated workaround.

          Axel
        • Sheri
          ... I made a test file and loaded it in both 5.7 and 5.8 and both seemed to handle my test file the same. But that s not to say that my test conditions match
          Message 4 of 5 , Apr 5 6:51 AM
          • 0 Attachment
            --- In ntb-clips@yahoogroups.com, Axel Berger <Axel-Berger@...> wrote:
            >
            > ebbtidalflats wrote:
            > > One way to deal with this is to use a regular expression
            >
            > Doesn't help. The file definitely contains 0a as well as the normal
            > 0d0a, but after opening it in NoteTab all these are changed to 0d0a.
            > A search for [^\r]\n finds nothing. This means just opening that
            > file in NoteTab changes it and the very things I need to look for
            > are no longer there. I may have to devise a complicated workaround.
            >
            > Axel
            >

            I made a test file and loaded it in both 5.7 and 5.8 and both seemed to handle my test file the same. But that's not to say that my test conditions match your file. My test file had:

            One[CRLF]
            Two[LF]Three[CR]
            Four[CRLF]

            ^L finds the single LF and no other. All the others are found by ^P (except the single LF). It appears the single CR has been converted to CRLF, it is not found by ^C. But the behavior is the same in 5.7. The file also looks the same when loaded in both versions with no linebreak at the single LF. Finally I tried saving the file in NoteTab to a new file in both versions, and this was also the same. In both cases, the single Carriage Return (0D) became 0D0A and the single Line Feed (0A) remained unchanged.

            Maybe what you think were single line feeds were actually single carriage returns?

            Regards,
            Sheri
          • Axel Berger
            ... No, when things began not to work as expected I checked everything in the Hex view of Totalcommander. The raw files I m dealing with are in the Atari or
            Message 5 of 5 , Apr 5 1:03 PM
            • 0 Attachment
              Sheri wrote:
              > Maybe what you think were single line feeds were actually
              > single carriage returns?

              No, when things began not to work as expected I checked everything
              in the Hex view of Totalcommander. The raw files I'm dealing with
              are in the Atari or nearly the CP437 character set. As they usually
              need converting anyway one more conversion won't hurt, so I'm now
              writing caracter 219 ($DB) instead of the 0A.

              I then hit two more problems:

              1) Loading the file as DOS ASCII converts the $DB to space, no good.

              2) Loaded as Ansi I can easily replace the $DB, shown as Û (capital
              U with circumflex). But in a clip neither the cut and pasted Û nor
              ^$DectoChar(219)$ worked. (^$DectoChar(219)$ as a clip on its own
              writes the correct character into a file though.) I was just
              starting to cry for help here again when I tried the third option,
              and voilà, using Regex and \xDB did the trick.

              Axel
            Your message has been successfully submitted and would be delivered to recipients shortly.