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

Re: [Clip] Re: Linefeeds

Expand Messages
  • 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 1 of 5 , Apr 5, 2009
    • 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 2 of 5 , Apr 5, 2009
      • 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 3 of 5 , Apr 5, 2009
        • 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.