check or scan _without_ retesting sectors?

In message , Lostgallifreyan
writes:
"J. P. Gilliver (John)" wrote in
:

Ctrl-M being of course
carriage return [without line feed].

I thought it was 0A only, not 0D only, but I just read that in Unix it IS the

Ctrl-A: 01
Ctrl-B: 02
..
..
..
Ctrl-H: 08 (BS, backspace [NOT the same as delete])
Ctrl-I: 09 (HT, horizontal tab)
Ctrl-J: 0A (LF, line feed)
Ctrl-K: 0B (can't remember this one, though I think it might be VT,
vertical tab)
Ctrl-L: 0C (FF, form feed)
Ctrl-M: 0D (CR, carriage return)
....
Basically, Ctrl took 40 (hex) off the ASCII code of the capital letter.
("A" is 65, 41 hex.)

CR and not both. DOS's EDIT.COM moves a cursor to a new line and generates
0D0A each time it's used in a file. It may be that Ctrl+M was meant to
emulate the full use of the carriage return lever and Unix omitted the CR

Ctrl-M is, in its simplest form, CR without LF - but many
implementations might add the LF.
[]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

Often at work I wish they'd pay me what I'm worth, but sometimes I'm glad they
don't. (BrritSki, in uk.media.radio.archers, on 2000-12-25.)

"J. P. Gilliver (John)" wrote in
:

Difficult to talk in
generalities in this sort of context.


I think that makes it difficult, but as far as I know, the \r and \n are both
direct mappings for go to start of current line, and go down to next line,
respectively. Interpretations may vary (and clearly do in different OS's),
but I assumed that as the mapping is direct in Lua, which is cross platform,
and in any RegExp I know of, that they were both true to the C code they're
usually written in.

One case for interpretation is clear in text editors in WIndows (and maybe
elsewhere), where \n on its own goes to the start of a new line because
otherwise it has to create enough spaces to put the cursor right below where
it was. As they won't generate spaces unless directly asked to do so, they
respond to \r\n and \n the same way. And also to \r for consistency, and
because the Enter key only generates that one anyway.

I just dug up something I did with TCC (Tiny C Compiler) a couple of years
ago when I was considering learning C and the Windows API. I didn't follow up
but I did enough to let me test what happens if you compile with a text
string containing \n, and again with \r, and a hex editor proves that the
mapping to 0A and 0D respectively, is literal. The message box responded to
both in the same way, start of new line. I imagine that is true if Lua is
running on Linux or BSD too, but C and RegExp clearly prerve the distinction,
as it would matter if the string were part of something sent by a comms
program.

"J. P. Gilliver (John)" wrote in
:

Basically, Ctrl took 40 (hex) off the ASCII code of the capital letter.
("A" is 65, 41 hex.)


That helps with memorising.

Ctrl-M is, in its simplest form, CR without LF - but many
implementations might add the LF.


In my other post I showed how a program coded in C in Windows (and likely
other OS's as the compiler was written for those too, as is wxLua) will treat
both CR and LF the same in displayed messages while preserving the exact
mapping of codes. As far as I know, in both subsystems, you won't get one
appended to the other or a replacement, unless that's directly expressed in
code by the coder's action. That would be needed because so many
interpretations may be made, not by other machines, but by other coders, that
the only way to get any grip on it is to have full control.

Btw, I think I left out one stage on my newline fix pseudo-code.
This would work though:

CRLF LF
LFCR LF
CR LF
(If Unix format file, save now)
LF CRLF
(If Windows save now, else if Mac, CRLF CR then save)

The second line is what was missing before.
(Not for terminals, this idea is just for files intended to be opened in text
editors.)

Lostgallifreyan wrote in
:

I just dug up something I did with TCC (Tiny C Compiler) a couple of
years ago when I was considering learning C and the Windows API. I
didn't follow up but I did enough to let me test what happens if you
compile with a text string containing \n, and again with \r, and a hex
editor proves that the mapping to 0A and 0D respectively, is literal.
The message box responded to both in the same way, start of new line.

I also tried \r\n and \n\r to see if either were treated as two newlines for
display purposes in message boxes. They aren't, both are collapsed into an
assumption of one. But \r\n\r and \n\r\n will both be treated as two lines.

This seems to be the same logic as I ended up with in my text file newline
code fix.

CRLF LF
LFCR LF
CR LF
(If Unix format file, save now)
LF CRLF
(If Windows save now, else if Mac, CRLF CR then save)

It's as if Windows Explorer applies a very similar fix when displaying
messages, and it may be the same in most OS shells, though as wxLua is coded
to use native controls on Linux or BSD as it does in Windows, other OS's may
render it differently to what I saw.

"J. P. Gilliver (John)" wrote in
:

It was my - not very deep - understanding that "\n" in C meant the
newline _concept_, which might translate to CRLF or LFCR or possibly
even just CR or just LF, depending on implementation, whereas "\r"
actually translated directly to the single byte

I thought of something else. While the CR and LF (and \r and \n in C code or
RegExp) definitely map to exact codes (0D, and 0A), and the order CRLF can be
traced back to the mechanics of typewriters that release the carriage before
scrolling the platen with a full motion of the lever, there is another
convention that defines this, likely predating the typewriter.

X axis motion before Y axis motion. The choice of X and Y themselves, to
define axes, for the order they appear in the alphabet. Which begs the
question why the same convention wasn't taken when picking ASCII control
codes, but never mind...