Re: [Clip] Re: Linefeeds
- ebbtidalflats wrote:
> One way to deal with this is to use a regular expressionDoesn'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.
- --- In firstname.lastname@example.org, Axel Berger <Axel-Berger@...> wrote:
>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:
> 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.
^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?
- Sheri wrote:
> Maybe what you think were single line feeds were actuallyNo, when things began not to work as expected I checked everything
> single carriage returns?
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.