On 30/01/2024 16:49, David Brown wrote:
>
> If the program can reasonably be expected to generate binary output,
> then it is the user's fault if they do this accidentally.  Examples
> shown in this thread include cat and zcat - that's what these programs do.
>
> Sometimes people make mistakes, and try to "cat" (or "type") non-text
> files.  Mistakes happen.
>
>
Elsethred [David Brown]
> I wonder if there is any *nix program older or simpler than "cat" - a
> program that simply passes its input files or the stdin to stdout.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 30/01/2024 16:25, David Brown wrote:
>> On 30/01/2024 16:49, Malcolm McLean wrote:
>>>
>>> Which is my experience for the sort of programming that I do.
>[stderr less used than stdout]
>>> Similarly there is no function "write`" that passes binary data to
>>> standard output by default.
>>
>> What would that gain?  One fewer parameters to fwrite() ?
>>
>Yes. printf() could easily have been omitted and fprintf() only
>provided.

IIRC, printf() existed even before fprintf was invented and
it was used by a whole lot of code when the C standardization
efforts began.

I suspect that most modern C libraries have printf effectively call
fprintf(stdout) internally (or at least a common function to
process the format string & varargs).

bart <bc@freeuk.com> writes:
>On 30/01/2024 16:49, David Brown wrote:
>
>
>> Sometimes people make mistakes, and try to "cat" (or "type") non-text
>> files.  Mistakes happen.
>
>
>If you routinely write pure binary data to stdout, then users are going
>to see garbage a lot more often.

Why do you believe that? Most users are capable of RTFM.

On 30/01/2024 19:29, Malcolm McLean wrote:
> On 29/01/2024 21:00, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 29/01/2024 16:18, David Brown wrote:
>>>> On 28/01/2024 20:49, Malcolm McLean wrote:
>>>>> On 28/01/2024 18:24, David Brown wrote:
>>>>> I'd expect that most general purpose programs written by Norwegians
>>>>> use an English interface, even if it isn't really expected that the
>>>>> program will find an audience beyond some users in Norway. Except
>>>>> of course for programs which in some way are about Norway.
>>>> Why?
>>>>
>>> Generally programmers are educated people and educated people use
>>> English for serious purposes. Not always of course and Norway might be
>>> an exception. But I'd expect that in a Norweigian university, for
>>> example, it would be forbidden to document a program in Norwegian or
>>> to use non-English words for identifiers. And probably the same in a
>>> large Norwegina company. I might be wrong about that and I have never
>>> visited Norway or worked for a Norweigian employer (and obviously I
>>> couldn't do so unless the policy I expect was followed).
>>
>> You assert that "educated people use English for serious purposes".
>> I don't have the experience to refute that claim, but I suspect
>> it's arrogant nonsense.  I could be wrong, of course.
>
> Everything which is at all intellectually serious is these days written
> in English. It's the new Latin. It's the language all educated people
> use to communicate with each other when discussing scientific,
> philosophical, or scholarly matters. And also technical matters to a
> large extent.
> There are a few exceptions but very few. I remember a discussion about
> whether you could get away with organising a scientific conference in
> French, in France, and the conclusion was that you could not. Even in
> France. However the French are very reluctant to concede, which is why
> the discussion took place at all.
>
> If a large Norwegian company allows programmers to document software in
> Norwegian, then it cannot employ non-Norwegian programmers to work on
> it. So I would imagine that this would be forbidden, But I've never
> actually worked for a Norwegian company and I don't actually know. David
> Brown, to be fair, does work for a Norwegian company so he might know
> better. But he asks "why?" and I gave the reason.
>

So your reasoning is "Scholars use English. Scholars are serious.
Therefore, anything serious is scholarly and consequently in English".

You do know that Monty Python's Holy Grail is entertainment, not a
education in logic?

When you are in such a deep hole, the wise thing would be to stop digging.

On 30/01/2024 17:55, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 30/01/2024 16:49, Malcolm McLean wrote:
>>
>>> The fact that there is no
>>> similar function for standard error suggests that wanting to pass
>>> formatted text to error is a less common requirement.
>>
>> stderr is a newer invention than stdout and stdin.
>
> c'est what?
>

According to Wikipedia (it's not infallible, but it knows better than me
here) :

"""
Standard error was added to Unix in the 1970s after several wasted
phototypesetting runs ended with error messages being typeset instead of
displayed on the user's terminal.[4]
"""

<https://web.archive.org/web/20200925010614/https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html>

"""
One of the most amusing and unexpected consequences of phototypesetting
was the Unix standard error file (!). After phototypesetting, you had to
take a long wide strip of paper and feed it carefully into a smelly, icky
machine which eventually (several minutes later) spat out the paper with
the printing visible.

One afternoon several of us had the same experience -- typesetting
something, feeding the paper through the developer, only to find a single,
beautifully typeset line: "cannot open file foobar" The grumbles were
loud enough and in the presence of the right people, and a couple of days
later the standard error file was born...
"""

stdout and stdin were apparently available in FORTRAN in the 1950's.

But you are more likely to know things first hand, or at least second
hand, so if you can correct both me and Wikipedia, I'd be happy with that.

On 30/01/2024 16:33, Malcolm McLean wrote:
>>
> C plays fast and loose with the char type. But you can't pass embedded
> nuls. These are so common in binary data that in  practis=ce you can't
> use %s for binary data at all.

Nobody uses printf to output binary data. fwrite(3) would be common, as
would write(2).

Maybe you could use printf("%c%c%c" ... but it'd be beyond tedious.

On 30/01/2024 18:39, Malcolm McLean wrote:
> On 30/01/2024 16:49, David Brown wrote:
>>
>> If the program can reasonably be expected to generate binary output,
>> then it is the user's fault if they do this accidentally.  Examples
>> shown in this thread include cat and zcat - that's what these programs
>> do.
>>
>> Sometimes people make mistakes, and try to "cat" (or "type") non-text
>> files.  Mistakes happen.
>>
>>
> Elsethred [David Brown]
> > I wonder if there is any *nix program older or simpler than "cat" - a
> > program that simply passes its input files or the stdin to stdout.

But, nobody expects piping a binary file to a tty to "work".

On 30/01/2024 19:22, bart wrote:
> On 30/01/2024 16:49, David Brown wrote:
>
>>> You just want to have a go at Windows don't you?
>>>
>>> I was using CRLF line-endings in 1970s, they weren't an invention of
>>> Windows, which didn't exist until the mid-80s and didn't become
>>> popular until the mid-90s.
>>
>> CRLF line endings were the invention of printers or teletype machines.
>> It took time to move print heads from the end of one line to the
>> beginning of the next, and separating the "carriage return" and "line
>> feed" commands made timings easier.  It also let printer implementers
>> handle the two operations independently - occasionally people would
>> want to do one but not the other.
>>
>> The use of CRLF as a standard for line endings in files was, I
>> believe, from CP/M - which came after Unix and Multics, which had
>> standardised on LF line endings.  (Most OS's before that made things
>> up as they choose, rather than being "standard", or used record-based
>> files, punched cards, etc.)
>>
>> So CRLF precedes Windows quite significantly.
>>
>> (I have no idea why Macs picked CR - perhaps they just wanted to be
>> different.)
>>
>>>
>>> So, how did C deal with CRLF in all those non-Windows settings?
>>>
>>
>> The difference between "text" and "binary" streams in C is, in
>> practice, up to the implementation.  That can be the implementation of
>> the C library, or the OS functions (or DLLs/SOs) that the C library
>> calls. The norm is that you use "\n" for line endings in the C code -
>> what happens after that, for text streams, is beyond C.
>>
>> The reason C distinguishes between text and binary streams is that
>> some OS's distinguish between them.
>>
>>>
>>>> Regardless of your digression, stdout is still an unformatted
>>>> stream of bytes.   Any structure on that stream is imposed
>>>> by the -consumer- of those bytes.
>>>
>>> Of course. But it still a bad idea to write actual output that you
>>> KNOW does not represent text, to a consumer that will expect text.
>>>
>>
>> That's just a specific example of "it's a bad idea for a program to
>> behave in a way that a reasonable user would not expect".  Which is,
>> of course, true - but not a big surprise.
>>
>>> For example to a terminal window, which can happen if you forget to
>>> redirect it.
>>
>> If the program can reasonably be expected to generate binary output,
>> then it is the user's fault if they do this accidentally.  Examples
>> shown in this thread include cat and zcat - that's what these programs
>> do.
>>
>> Sometimes people make mistakes, and try to "cat" (or "type") non-text
>> files.  Mistakes happen.
>
>
> If you routinely write pure binary data to stdout, then users are going
> to see garbage a lot more often.

Or they will learn not to try to view the output of the programs.

I can see there being a problem if a program looks like it should give
text output, or sometimes gives text output, but it sometimes gives
binary output.

If you have a program like that, then it probably makes sense to have a
flag to say "output the data to stdout" and the default being writing to
a file.

So don't misunderstand me here - I'm all in favour of making programs
user-friendly, and not filling people's terminals with junk
unexpectedly. It's just that sometimes binary output on stdout is
excepted and convenient.

>
> I gave an example earlier when displaying a binary file with 'type' was
> better-behaved than with 'cat', since 'type' stops at the first 1A byte.
>

That would make "type" better behaved if you only use it for looking at
text files. "cat" is used for many different things, and stopping at
0x1a (or 0x00) would be bad behaviour for that program. They are not
the same program, and do different things (even if "cat" can also do
everything that "type" can.

> I used this in my binary formats by adding 1A after the signature, so
> you if you attempted to type it out, it wouldn't go mad. Here's another
> example:
>
>    c:\sc>type tree.scd
>    SCD
>
> (.scd is a binary file containing CAD drawing data.)
>

If that suits your needs, fine. I haven't used "type" for decades. (In
almost all cases, "more" is better. And if I have normal utilities,
"less" is better still.)

> If I again do that with 'cat' under WSL, it's goes even crazier. In
> starts to try and interpret of the output as commands (with what
> program, I don't know), with lots of Bell sounds, and I can't get back
> to the WSL prompt.
>
> It's just very, very sloppy.

No, it is very, very correct. The program is doing what it is intended
to do. You just think it should have been designed to do something
else. A "cat" program that stopped after 0x1a would be completely broken.

It's fine that you prefer "type" to "cat". I wouldn't use either of
them - I'd use "less" for viewing a file. (You'd have similar issues
with unhelpful output if you tried to use "less" on a binary file, but
only one screenful.) But I'd use "cat" for concatenating files, or for
sourcing a file to pipe into something else. I realise joining multiple
commands with pipes is not common in Windows - that's fine too. You use
what suits you best. But it makes no sense to blame one program for not
functioning like a very different program - especially when the
difference is a misfeature, as often as not.

scott@slp53.sl.home (Scott Lurndal) writes:
> bart <bc@freeuk.com> writes:
>>On 30/01/2024 15:00, Scott Lurndal wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> I must admit that it's nothing I have ever done or considered doing.
>>>>
>>>> However standard output is designed for text and not binary ouput.
>>>
>>> That was never the case. stdout is a unformatted stream of bytes
>>> associated by default with file descriptor number one in the
>>> application.
>>>
>>> Long before windows was even a gleam in gates eye.
>>>
>>
>>I don't know what Windows has to do with it.
>>
>>The difference between text and binary byte streams is something
>>invented by C, so that conversions could be done for byte '\n' on
>>systems with alternate line-endings.
>
> No, it was invented to support windows CRLF line endings.

I'm skeptical that Windows specifically was the motivation. Also, I'm
not sure what you meant by "No" above. Windows is an example of a
system with alternate line-endings.

K&R1 (1978) documents fopen() but doesn't mention the binary vs. text
distinction. ANSI C (1989) does. Windows 1.0 was released in 1985 --
but it inherited CRLF line endings directly from MS-DOS, first released
in 1981. CP/M, from which MS-DOS got its text file format, was first
released in 1974, close to the time that C first evolved from B.

VMS (now OpenVMS) was also a significant system at the time, and it had
some rather complex file formats, so the text/binary distinction was
likely important there as well.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 30/01/2024 16:49, David Brown wrote:
>> If the program can reasonably be expected to generate binary output,
>> then it is the user's fault if they do this accidentally.  Examples
>> shown in this thread include cat and zcat - that's what these
>> programs do.
>> Sometimes people make mistakes, and try to "cat" (or "type")
>> non-text files.  Mistakes happen.
>>
> Elsethred [David Brown]
>> I wonder if there is any *nix program older or simpler than "cat" -
> a > program that simply passes its input files or the stdin to
> stdout.

Terminals and terminal emulators are designed for textual data.
Writing arbitrary binary data to a terminal can cause problems.
(For that matter, writing UTF-8 text to a terminal that isn't
configured to recognize it can also cause problems.)

stdout doesn't necessarily go to a terminal.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 29/01/2024 21:00, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 29/01/2024 16:18, David Brown wrote:
>>>> On 28/01/2024 20:49, Malcolm McLean wrote:
>>>>> On 28/01/2024 18:24, David Brown wrote:
>>>>> I'd expect that most general purpose programs written by Norwegians
>>>>> use an English interface, even if it isn't really expected that the
>>>>> program will find an audience beyond some users in Norway. Except
>>>>> of course for programs which in some way are about Norway.
>>>> Why?
>>>>
>>> Generally programmers are educated people and educated people use
>>> English for serious purposes. Not always of course and Norway might be
>>> an exception. But I'd expect that in a Norweigian university, for
>>> example, it would be forbidden to document a program in Norwegian or
>>> to use non-English words for identifiers. And probably the same in a
>>> large Norwegina company. I might be wrong about that and I have never
>>> visited Norway or worked for a Norweigian employer (and obviously I
>>> couldn't do so unless the policy I expect was followed).
>> You assert that "educated people use English for serious purposes".
>> I don't have the experience to refute that claim, but I suspect
>> it's arrogant nonsense. I could be wrong, of course.
>
> Everything which is at all intellectually serious is these days
> written in English. It's the new Latin. It's the language all educated
> people use to communicate with each other when discussing scientific,
> philosophical, or scholarly matters. And also technical matters to a
> large extent.

Even if that's true, you assertion was about user interfaces.

Are you under the impression that mobile phones show their messages only
in English because all their users are scholars?

Are you aware of the existence of medical devices (my current $DAYJOB)
that can be configured to display messages in any of a number of
languages?

[...]

> If a large Norwegian company allows programmers to document software
> in Norwegian, then it cannot employ non-Norwegian programmers to work
> on it. So I would imagine that this would be forbidden, But I've never
> actually worked for a Norwegian company and I don't actually
> know. David Brown, to be fair, does work for a Norwegian company so he
> might know better. But he asks "why?" and I gave the reason.

Correct, you don't actually know. Why doesn't that prevent you from
making assertions rather than asking questions, so that you can learn
something from people who know more than you do?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 30/01/2024 19:29, David Brown wrote:
> On 30/01/2024 17:55, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 30/01/2024 16:49, Malcolm McLean wrote:
>>>
>>>> The fact that there is no
>>>> similar function for standard error suggests that wanting to pass
>>>> formatted text to error is a less common requirement.
>>>
>>> stderr is a newer invention than stdout and stdin.
>>
>> c'est what?
>>
>
> According to Wikipedia (it's not infallible, but it knows better than me
> here) :
>
> """
> Standard error was added to Unix in the 1970s after several wasted
> phototypesetting runs ended with error messages being typeset instead of
> displayed on the user's terminal.[4]
> """
>
> <https://web.archive.org/web/20200925010614/https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html>
>
> """
> One of the most amusing and unexpected consequences of phototypesetting
> was the Unix standard error file (!).   After phototypesetting, you had to
> take a long wide strip of paper and feed it carefully into a smelly, icky
> machine which eventually (several minutes later) spat out the paper with
> the printing visible.
>
> One afternoon several of us had the same experience -- typesetting
> something, feeding the paper through the developer, only to find a single,
> beautifully typeset line: "cannot open file foobar"   The grumbles were
> loud enough and in the presence of the right people, and a couple of days
> later the standard error file was born...
> """
>

That explains a lot. It is ludicrous to just blindly send data to
stdout, in cases like this. Send it to a file, where it can be neatly
self-contained, and then send that to the device. Or least use a device
handle like 'stdprinter'.

Just something that will segregate output that is intended for the
terminal, from data output.

Clearly every process in Unix was some sort of batch program.

With an interactive application, you have an on-going dialog with the
user. But if EVERYTHING is sent to stdout, how on earth do you switch
between output for the user, and output for the whatever needs to have
been setup to hang onto stdout?

Don't tell me that you need to use stderr for the interactive dialog and
stdout for data!

It just got things wrong from the start. It doesn't look like much as
changed.

>
> stdout and stdin were apparently available in FORTRAN in the 1950's.

I spent a year writing FORTRAN on mainframes and minicomputers. I don't
remember anything like that.

And my coding involved outputting to a range of imaging peripherals
including vector graphics terminals (Tektronix).

Meanwhile other software of mine since then could output to an endless
variety of peripherals, often several kinds within the same program.

I don't recall any nonsense where you just wrote necessary data to the
equivalent of STDOUT, and hoping something at the other end would do
something sensible with it.

For a start, that would be the only thing the program could do: dump
stuff to STDOUT then terminate.

But hey, if Unix does it then it must be right!

On 2024-01-30, Scott Lurndal <scott@slp53.sl.home> wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>On 30/01/2024 16:25, David Brown wrote:
>>> On 30/01/2024 16:49, Malcolm McLean wrote:
>>>>
>>>> Which is my experience for the sort of programming that I do.
>>[stderr less used than stdout]
>>>> Similarly there is no function "write`" that passes binary data to
>>>> standard output by default.
>>>
>>> What would that gain?  One fewer parameters to fwrite() ?
>>>
>>Yes. printf() could easily have been omitted and fprintf() only
>>provided.
>
> IIRC, printf() existed even before fprintf was invented and
> it was used by a whole lot of code when the C standardization
> efforts began.

Well, actually, printf and fprintf were conflated into one
function in early Unix!

If the first argument of printf was a number instead of a
format string, then it indicated the device to send output
to (it was an index in the table of FILE structures or something).
In that case, the second argument was the format string:

printf("hello, %s\n", "world!"); /* print on standard output */

printf(1, "hello, %s\n", "world!"); /* likewise */

printf(2, "hello, %s\n", "world!"); /* likewise */

Or something like that; I may have some detail wrong.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

bart <bc@freeuk.com> writes:
[...]
> But hey, if Unix does it then it must be right!

As usual, you mistake explanations of how Unix works for assertions that
the way Unix works is the best of all possible worlds.

Can't you just accept explanations as explanations?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 30/01/2024 20:06, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 29/01/2024 21:00, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> On 29/01/2024 16:18, David Brown wrote:
>>>>> On 28/01/2024 20:49, Malcolm McLean wrote:
>>>>>> On 28/01/2024 18:24, David Brown wrote:
>>>>>> I'd expect that most general purpose programs written by Norwegians
>>>>>> use an English interface, even if it isn't really expected that the
>>>>>> program will find an audience beyond some users in Norway. Except
>>>>>> of course for programs which in some way are about Norway.
>>>>> Why?
>>>>>
>>>> Generally programmers are educated people and educated people use
>>>> English for serious purposes. Not always of course and Norway might be
>>>> an exception. But I'd expect that in a Norweigian university, for
>>>> example, it would be forbidden to document a program in Norwegian or
>>>> to use non-English words for identifiers. And probably the same in a
>>>> large Norwegina company. I might be wrong about that and I have never
>>>> visited Norway or worked for a Norweigian employer (and obviously I
>>>> couldn't do so unless the policy I expect was followed).
>>> You assert that "educated people use English for serious purposes".
>>> I don't have the experience to refute that claim, but I suspect
>>> it's arrogant nonsense. I could be wrong, of course.
>>
>> Everything which is at all intellectually serious is these days
>> written in English. It's the new Latin. It's the language all educated
>> people use to communicate with each other when discussing scientific,
>> philosophical, or scholarly matters. And also technical matters to a
>> large extent.
>
> Even if that's true, you assertion was about user interfaces.
>
> Are you under the impression that mobile phones show their messages only
> in English because all their users are scholars?
>
Things tend to trickle down.
Teenagers from non-English speaking countries hum along to pop songs in
English. And whilst programmers aren't usually scholars, if they are C
programmers they will use a programming language with keywords based on
English.
And you will likley get quite a bit of English coming through the mobile
phone.
Linus Torvald's native language is Finnish, for example. But git was
released in English. There might be Finnish language bindings for it
now, but I'm pretty sure not in the original version. Similarly Bjarne
Strousup is Swedish, but C++ uses keywords like "class" and "friend",
not the Swedish terms.
Now I think that would rub off on Norwegian programmers. It would be
surprising of it did not.
> Are you aware of the existence of medical devices (my current $DAYJOB)
> that can be configured to display messages in any of a number of
> languages?
>
Some software is internationalised. But it takes quite a lot of
resources to translate software. With medical device software the
software is likely so expensive to develop anyway because of all the
safety critical portions that the cost is tolerable. Our software has
purely English user interfaces. It was something we looked at, but it
would have been expensive and made the code base harder to manange, and
the users said that the benefit to them was marginal as they spoke
enough English to understand a few simple GUI labels. I think our
experience is more typical, but some people will no doubt make out that
it is narrow and parochial.
>
> [...]
>
> Correct, you don't actually know. Why doesn't that prevent you from
> making assertions rather than asking questions, so that you can learn
> something from people who know more than you do?
>
I'm a qualified scientist, amongst other things. In science, the things
that you know are usually either quite basic and covered in the first
degree, or they are not terribly interesting. What matters is what you
don't actually know, but believe to be the case, based on sound evidence
and reasoning. And I believe it to be the case that English is used very
widely in Norway. And in fact, if David Brown, who is in a position to
know, asserts this not to be the case, I'd put it down to his
contentious nature and tend to dismiss it. Now of course I could have
misled myself. But I doubt it.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 1/30/24 11:49, David Brown wrote:
....
> If the program can reasonably be expected to generate binary output,
> then it is the user's fault if they do this accidentally. Examples
> shown in this thread include cat and zcat - that's what these programs do.

? There's no problem using cat to concatenate binary files. I've used
'split' to split binary files into smaller pieces, and then used 'cat'
to recombine them, and it worked fine. I don't remember why, but I had
to transfer the files from one place to another by a method that imposed
an upper limit on the size of individual files.

David Brown <david.brown@hesbynett.no> writes:
>On 30/01/2024 17:55, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 30/01/2024 16:49, Malcolm McLean wrote:
>>>
>>>> The fact that there is no
>>>> similar function for standard error suggests that wanting to pass
>>>> formatted text to error is a less common requirement.
>>>
>>> stderr is a newer invention than stdout and stdin.
>>
>> c'est what?
>>
>
>According to Wikipedia (it's not infallible, but it knows better than me
>here) :
>
>"""
>Standard error was added to Unix in the 1970s after several wasted
>phototypesetting runs ended with error messages being typeset instead of
>displayed on the user's terminal.[4]

Ok. I had incorrectly assumed you were referring to the late 80's
when C standardization was underway.

It was certainly there by unix v6 which was the first version I
used in the late 70's.

On Tue, 30 Jan 2024 17:49:57 +0100, David Brown wrote:

> The use of CRLF as a standard for line endings in files was, I believe,
> from CP/M ...

Which I think copied it from DEC minicomputer systems.

Fun fact: on some of those DEC systems (which I used when they were still
being made), you could end a line with CR-LF, or LF-CR-NUL.

What was the NUL for? Padding. Why did it need padding? (This was before
CRT terminals.)

On Tue, 30 Jan 2024 11:50:35 -0800, Keith Thompson wrote:

> VMS (now OpenVMS) was also a significant system at the time, and it had
> some rather complex file formats ...

It relied on extra file metadata called “record attributes” in order to
make sense of the file format. It was quite common to transfer files from
other systems, and have them not be readable until you had set appropriate
record attributes on them. Picky, picky, I know.

Apparently Linus Torvalds used VMS for a while, and hated it.

On Tue, 30 Jan 2024 15:21:01 +0000, Malcolm McLean wrote:

> Most systems run Windows where the model of piping from standard output
> to standard input of the next program is much less used than in Unix,
> this is true. That sometimes generates a feeling of superiority amongst
> those who use the less common, often more expensive Unix systems. It's
> very silly, but that's how people think.

Also we can do select/poll on pipes on *nix systems, you can’t on Windows.

On Tue, 30 Jan 2024 21:04:56 +0000, Malcolm McLean wrote:

> Linus Torvald's native language is Finnish, for example.

No, it would be Swedish. He’s an ethnic Swede, from Finland.

On Tue, 30 Jan 2024 09:13:07 +0000, Malcolm McLean wrote:

> However standard output is designed for text and not binary ouput.
> Whilst there is a "printf()" which operates on standard output by
> default, there are no functions which write binary data to standard
> outout by default, for example.

putchar(2).

On Tue, 30 Jan 2024 17:25:31 +0100, David Brown wrote:

> Mixing binary data with formatted text data is very unlikely to be
> useful.

PDF does exactly that. To the point where the spec suggests putting some
random unprintable bytes up front, to distract format sniffers from
thinking they’re looking at a text file.

On Tue, 30 Jan 2024 20:29:17 +0100, David Brown wrote:

> stdout and stdin were apparently available in FORTRAN in the 1950's.

There was a convention that channel 5 was the card reader, and 6 was the
line printer.

When interactive systems came along later, this became channel 5 for
keyboard input, and 6 for terminal output.

What happened to channels 1, 2, 3 & 4? Don’t know.

On Tue, 30 Jan 2024 19:39:24 +0000, Richard Harnden wrote:

> Nobody uses printf to output binary data.

Do terminal-control escape sequences count?