fgets() equivalent?

[Thomas Dickey]

Fortunately, Thompson was intelligent enough to realize that the
control characters for printing devices should not determine the
representation of text files. The conversion is tucked away into the
kernel, and can be turned on and off.

....and an equivalent optional feature is built into most terminal emulators.
That's the LNM mode documented in ECMA-48, e.g., (from xterm's documentation):

CSI Pm h Set Mode (SM)
Ps = 2 0 -> Automatic Newline (LNM)
CSI Pm l Reset Mode (RM)
Ps = 2 0 -> Normal Linefeed (LNM)

The VT100 terminal, which is widely emulated today, also works this
way, and so Unix systems in general nearly always have the ONLCR flag
turned on when communicating with their own character consoles or
terminal emulators like xterm, etc.

....of course the terminal drivers don't use the mode - it's done
by sending explicit CR/LF codes.

 

[David Thompson]

David Craig wrote: *** and top-posted - fixed ***

This was usually handled by having the terminal driver emit "CR,
LF, DC3" to prompt for a new line. At line end, the echoing
machinery would emit "DC1, CR". I think I have the sequence
right. At any rate, there was enough idle time for the carriage to
recover, and the sequences would also stop/start the tape reader,
if present and loaded. When the input line was half duplex those
sequences would also prompt the sending device to unload another
line.

I don't think 'usually' is right; I saw this only on a few
'half-duplex' systems like IBM VM/370, and never on any Unix.
(Although there has been such a great profusion of Unices I can't
speak for all.) Where it was used you have it backwards: DC1=0x11 to
prompt/enable, DC3=0x13 to 'hold it there, buddy'.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[David Thompson]

Fortunately, Thompson was intelligent enough to realize that the
control characters for printing devices should not determine the
representation of text files. The conversion is tucked away into the
kernel, and can be turned on and off.

Or at least in the tty drivers which are in the system but (nowadays)
not necessarily in the kernel.

The people who designed CR-LF into the various Internet protocols
really dropped the ball. There was an opportunity to fix this
braindamage in HTTP, but alas.

I disagree strongly. For TELNET it was definitely right to use the
(only) meanings then standardized. For other protocols once you've
decided to go textlike (e.g. SMTP/NNTP) same principle -- and
personally I think that textlike, with its implications for reading
traces and monitors and debugging, was a significant factor in the
success of IP-stack. (But less so than free and implement-first.)

For FTP, where you do need to support arbitrary data, they did define
a character-independent 'structured' mode. Which is hardly ever used
nowadays, though when dinosaur (systems) roamed the earth it was.

Mediatype text/html in HTTP does allow any of CR LF or CRLF. Of course
non-PRE whitespace is collapsed in HTML anyway (like in C!).

<snip rest>
- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[David Thompson]

Finally, some one who can relate to history. Thanks David.

The following note is not specifically to you, just in general.

In general, the terms of "raw" vs "cooked" is broadly applied to
basically means non-translation vs translation. Generally, we cook
something in order to establish some structural consistency either for
input or output.

Specifically, when it comes to dealing with text vs binary ideas, in
general, we are talking about dealing with the control codes, ASCII code
0 to 31.

For file storage and we are mostly talking about three control codes
dealing with EOL (End of line) or EOF (End of File) entities.

<lf> 0x0A ^J
<cr> 0x0D ^M
<eof> 0x1D ^Z

(note, I am not using strict ASCII mnemonics here.)

^Z, sometimes used for EOF (but not universally, and as you note not
standardized), is 0x1A.

<snip rest including repeat>
- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[David Thompson]

(clc re-added, I don't have time to follow a new hierarchy)

J de Boyne Pollard wrote:

Not the case with all operating systems. Many systems like CP/M and some
mainframes have a record oriented file system, where the file is
represented as a sequence of records.

Most mainframes yes, and historically some minis, but not CP/M.
Unless you mean blocks -- CP/M had fixed-size blocks, normally 128B,
unrelated to the records (if any) stored in them.

CP/M also had a end-of-file > marker.

For text, right. Also RT-11, which similarly had 512B blocks.

Also non 8-bit byte systems may not view files as an octet > stream.

True but I don't see the relevance.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[CBFalconer]

I don't think 'usually' is right; I saw this only on a few
'half-duplex' systems like IBM VM/370, and never on any Unix.
(Although there has been such a great profusion of Unices I can't
speak for all.) Where it was used you have it backwards: DC1=0x11 to
prompt/enable, DC3=0x13 to 'hold it there, buddy'.

You're right - I have DC1 and DC3 interchanged. I forget exactly
what systems I saw this on, but I am certain about the HP3000. I
used it myself on micros talking to teletypes.

 

[Ben Voigt [C++ MVP]]

Mediatype text/html in HTTP does allow any of CR LF or CRLF. Of course

non-PRE whitespace is collapsed in HTML anyway (like in C!).

That's the payload, not the request envelope (which is the only thing
defined by HTTP). HTTP request and response must use CR+LF as line
terminator. The format of the payload is application-specific, HTML being
as you say whitespace agnostic, but still only one of many different
possible content types carried by HTTP.