"C" has been around almost forever - I bought the K&R book
when it was new on the shelves WAY back when.

We have all sorts of handy string functions and a zillion
other neat-o things in the various libraries - but no fcopy().
It seems so basic.

Admittedly, it's not hard to write one - a "makedirs()"+
source&dest files (and better xfer all the stat() stuff) -
but, I guess it's a historical question, why was one never
included in stdio.h or a near relative ?

On 08/05/2021 04:29, MSB wrote:
> "C" has been around almost forever - I bought the K&R book
> when it was new on the shelves WAY back when.
>
> We have all sorts of handy string functions and a zillion
> other neat-o things in the various libraries - but no fcopy().
> It seems so basic.
>
> Admittedly, it's not hard to write one - a "makedirs()"+
> source&dest files (and better xfer all the stat() stuff) -
> but, I guess it's a historical question, why was one never
> included in stdio.h or a near relative ?
>
I think you need to look back at what environment C and Unix started on
- a PDP-11 IIRC - to understand the philosophy: as little built in as
possible. with only 128K RAM to play woth, you dont want to have huge
libraries.

fcopy exists, it's called cp...at the Unix, rather than the C, level

--
Of what good are dead warriors? … Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory … The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.

MSB <Bit15_.us> writes:

> "C" has been around almost forever - I bought the K&R book
> when it was new on the shelves WAY back when.
>
> We have all sorts of handy string functions and a zillion
> other neat-o things in the various libraries - but no fcopy().
> It seems so basic.
>
> Admittedly, it's not hard to write one - a "makedirs()"+
> source&dest files (and better xfer all the stat() stuff) -
> but, I guess it's a historical question, why was one never
> included in stdio.h or a near relative ?

It may seem basic, but how about needed?
If something isn't needed why should someone create it?

--
Dan Espen

On Fri, 07 May 2021 23:29:37 -0400, MSB wrote:

> We have all sorts of handy string functions and a zillion other neat-o
> things in the various libraries - but no fcopy().

The reason is simpy that the vast majoity of the system C has
been ported on don't even know what a file is, therefore it is
not necessary to have it built in.

On Sat, 8 May 2021 09:20:59 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

>On 08/05/2021 04:29, MSB wrote:
>> "C" has been around almost forever - I bought the K&R book
>> when it was new on the shelves WAY back when.
>>
>> We have all sorts of handy string functions and a zillion
>> other neat-o things in the various libraries - but no fcopy().
>> It seems so basic.
>>
>> Admittedly, it's not hard to write one - a "makedirs()"+
>> source&dest files (and better xfer all the stat() stuff) -
>> but, I guess it's a historical question, why was one never
>> included in stdio.h or a near relative ?
>>
>I think you need to look back at what environment C and Unix started on
>- a PDP-11 IIRC - to understand the philosophy: as little built in as
>possible. with only 128K RAM to play woth, you dont want to have huge
>libraries.
>
>fcopy exists, it's called cp...at the Unix, rather than the C, level

Yes, but I got tired of composing a system() command - and it
didn't do ALL I wanted. My makedirs() not only parses out and
(possibly) creates the whole dest chain but also tries to open
a probe file there to confirm writability. The fcopy() bit copies
and transfers the permissions/owner/dates stuff AND has a
flag so you can allow, or disallow, overwrite of an existing
file of the same name. Not many lines of code ... so it's
just so weird 'C' never put it in a standard library.

PDP-11 (hallowed be its name) may not have had much
memory to play with, but the need for a clean safe file
copy still existed - you'd just do it with much smaller
buffers.

Gee ... I'd love a "modern" PDP-11 with the same basic
instructions - just in 64 bits :-)

Actually, emulators these days would be a LOT faster
than the original chipset ...but it's just not the same.

And a 68000-64/128 with all the modern speed features
would be heaven on earth.

Never got to program the PDP ... but I did some work
for the LSI-11 way back when. Almost the same, just
a bit clunkier.

A lot of the old chips had unique and interesting solutions
to certain problems. Remember the TMS-990/9900 ...
it handled a multi-user environment with on-chip methods,
allocating a new 64k 'workspace' for users/tasks in
system memory (which was better than on-chip cache
at the time). BLWP ... Branch And Load Workspace
Pointer .....

On Sat, 08 May 2021 06:42:01 -0400, Dan Espen <dan1espen@gmail.com>
wrote:

>MSB <Bit15_.us> writes:
>
>> "C" has been around almost forever - I bought the K&R book
>> when it was new on the shelves WAY back when.
>>
>> We have all sorts of handy string functions and a zillion
>> other neat-o things in the various libraries - but no fcopy().
>> It seems so basic.
>>
>> Admittedly, it's not hard to write one - a "makedirs()"+
>> source&dest files (and better xfer all the stat() stuff) -
>> but, I guess it's a historical question, why was one never
>> included in stdio.h or a near relative ?
>
>It may seem basic, but how about needed?
>If something isn't needed why should someone create it?

I would assert that "copy file" is SO basic and essential
that it should have been one of the first entries in some
standard library. We have rename(), we have remove(),
we have stat(). so why not fcopy() ???

Basically every other decent language HAS its version
of fcopy(), usually with a lot of useful options. Not 'C'.

It's not a real impediment, just weird. A "hole" in the
overall paradigm. If it was intentional - I'm trying to
find out why.

On Sun, 9 May 2021 21:41:44 +0000 (UTC), asdf <asdf@nospam.com> wrote:

>On Fri, 07 May 2021 23:29:37 -0400, MSB wrote:
>
>> We have all sorts of handy string functions and a zillion other neat-o
>> things in the various libraries - but no fcopy().
>
>The reason is simpy that the vast majoity of the system C has
>been ported on don't even know what a file is, therefore it is
>not necessary to have it built in.

Um ... disagree strongly. "Copy stuff" is an ultra-basic need.
Doesn't matter if it's CP/M or DOS or -ix .... most everything
DOES have a concept of a "file", or at least "block of binary
data on device".

So, I see it as weird 'C' never dealt with this early on.

Are K or R still alive ? Maybe we can ask.

On 09/05/2021 22:41, asdf wrote:
> On Fri, 07 May 2021 23:29:37 -0400, MSB wrote:
>
>> We have all sorts of handy string functions and a zillion other neat-o
>> things in the various libraries - but no fcopy().
>
> The reason is simpy that the vast majoity of the system C has
> been ported on don't even know what a file is, therefore it is
> not necessary to have it built in.
>
That's why fopen() doesn't exist either...
....sheesh

--
"It is an established fact to 97% confidence limits that left wing
conspirators see right wing conspiracies everywhere"

MSB <Bit15_.us> writes:

> On Sat, 08 May 2021 06:42:01 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>>MSB <Bit15_.us> writes:
>>
>>> "C" has been around almost forever - I bought the K&R book
>>> when it was new on the shelves WAY back when.
>>>
>>> We have all sorts of handy string functions and a zillion
>>> other neat-o things in the various libraries - but no fcopy().
>>> It seems so basic.
>>>
>>> Admittedly, it's not hard to write one - a "makedirs()"+
>>> source&dest files (and better xfer all the stat() stuff) -
>>> but, I guess it's a historical question, why was one never
>>> included in stdio.h or a near relative ?
>>
>>It may seem basic, but how about needed?
>>If something isn't needed why should someone create it?
>
> I would assert that "copy file" is SO basic and essential
> that it should have been one of the first entries in some
> standard library. We have rename(), we have remove(),
> we have stat(). so why not fcopy() ???
>
> Basically every other decent language HAS its version
> of fcopy(), usually with a lot of useful options. Not 'C'.
>
> It's not a real impediment, just weird. A "hole" in the
> overall paradigm. If it was intentional - I'm trying to
> find out why.

You have still not described why a C programmer would need a function
like this. I can't figure a use case except in backup. That hardly
makes it worthwhile to put this in libc.

So, now your claim is that fcopy is basic and "essential".
You are making that "essential" part up.

--
Dan Espen

On 10/05/2021 06.43, MSB wrote:
> On Sat, 08 May 2021 06:42:01 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> MSB <Bit15_.us> writes:
>>
>>> "C" has been around almost forever - I bought the K&R book
>>> when it was new on the shelves WAY back when.
>>>
>>> We have all sorts of handy string functions and a zillion
>>> other neat-o things in the various libraries - but no fcopy().
>>> It seems so basic.
>>>
>>> Admittedly, it's not hard to write one - a "makedirs()"+
>>> source&dest files (and better xfer all the stat() stuff) -
>>> but, I guess it's a historical question, why was one never
>>> included in stdio.h or a near relative ?
>>
>> It may seem basic, but how about needed?
>> If something isn't needed why should someone create it?
>
> I would assert that "copy file" is SO basic and essential
> that it should have been one of the first entries in some
> standard library. We have rename(), we have remove(),
> we have stat(). so why not fcopy() ???
>
> Basically every other decent language HAS its version
> of fcopy(), usually with a lot of useful options. Not 'C'.

Pascal doesn't. Not in the basic libraries, at least.

>
> It's not a real impediment, just weird. A "hole" in the
> overall paradigm. If it was intentional - I'm trying to
> find out why.

One reason would be that any function in the basic library was linked in
the final code even if not used, making it bigger. There would be many
other functions that also could be useful.

Sometime in the 90's, I compared the sizes of "Hello world!" made with
both Borland C and Borland Pascal. C version was 32 KB, BP was 3 KB.
Borland Pascal used a non standard linking method that only included the
code that was actually used in the program, producing much smaller code.

I don't remember if the extended libraries of Borland Pascal or C, which
allowed full text interfaces with mouse support and file browsing
functions included a file copy function or not. Funny that you could
edit text but not copy a file :-D

--
Cheers, Carlos.

MSB <Bit15_.us> wrote:
> On Sat, 08 May 2021 06:42:01 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>>MSB <Bit15_.us> writes:
>>
>>> "C" has been around almost forever - I bought the K&R book
>>> when it was new on the shelves WAY back when.
>>>
>>> We have all sorts of handy string functions and a zillion
>>> other neat-o things in the various libraries - but no fcopy().
>>> It seems so basic.
>>>
>>> Admittedly, it's not hard to write one - a "makedirs()"+
>>> source&dest files (and better xfer all the stat() stuff) -
>>> but, I guess it's a historical question, why was one never
>>> included in stdio.h or a near relative ?
>>
>>It may seem basic, but how about needed?
>>If something isn't needed why should someone create it?
>
> I would assert that "copy file" is SO basic and essential
> that it should have been one of the first entries in some
> standard library. We have rename(),

Rename is a syscall, which is why it is there.

> we have remove(),

Remove is also a syscall (unlink), which is also why it is in the
library.

> we have stat().

Stat is ultimately another syscall, which is why it is also there.

> so why not fcopy() ???

There is no "fcopy" syscall. So no 'fcopy' in libc.

> It's not a real impediment, just weird. A "hole" in the
> overall paradigm. If it was intentional - I'm trying to
> find out why.

Most of the basic C libaries are more-or-less simply C level interfaces
to the various Unix syscalls. As there is no "fcopy" syscall, there is
no fcopy() function in the basic C libraries.

Rich <rich@example.invalid> writes:
> MSB <Bit15_.us> wrote:
>> I would assert that "copy file" is SO basic and essential that it
>> should have been one of the first entries in some standard
>> library. We have rename(),
>
> Rename is a syscall, which is why it is there.
>
>> we have remove(),
>
> Remove is also a syscall (unlink), which is also why it is in the
> library.

Not always. For instance on some platforms it’s unlink, backing off to
rmdir if that didn’t work.

>> we have stat().
>
> Stat is ultimately another syscall, which is why it is also there.
>
>> so why not fcopy() ???
>
> There is no "fcopy" syscall. So no 'fcopy' in libc.
>
>> It's not a real impediment, just weird. A "hole" in the
>> overall paradigm. If it was intentional - I'm trying to
>> find out why.
>
> Most of the basic C libaries are more-or-less simply C level interfaces
> to the various Unix syscalls. As there is no "fcopy" syscall, there is
> no fcopy() function in the basic C libraries.

This argument makes very little sense. There are loads of C library
functions that aren’t syscalls; strcpy for instance.

I suspect the real answer is that nobody cared enough to add it as a
standard function.

As it happens there is a copy_file_range syscall in the Linux kernel,
reflecting that the kernel can do a better job of copying files than a
userland process, in some situations. So it’s not a particularly silly
suggestion.

--
https://www.greenend.org.uk/rjk/

On 2021-05-10, MSB <Bit15_.us> wrote:
> On Sun, 9 May 2021 21:41:44 +0000 (UTC), asdf <asdf@nospam.com> wrote:
>
>>On Fri, 07 May 2021 23:29:37 -0400, MSB wrote:
>>
>>> We have all sorts of handy string functions and a zillion other neat-o
>>> things in the various libraries - but no fcopy().
>>
>>The reason is simpy that the vast majoity of the system C has
>>been ported on don't even know what a file is, therefore it is
>>not necessary to have it built in.
>
> Um ... disagree strongly. "Copy stuff" is an ultra-basic need.
> Doesn't matter if it's CP/M or DOS or -ix .... most everything
> DOES have a concept of a "file", or at least "block of binary
> data on device".
>
> So, I see it as weird 'C' never dealt with this early on.
>
> Are K or R still alive ? Maybe we can ask.

Your "most everything" does not include the EKG/ECG sensor unit I
and a few other developers worked on several years ago. Okay,
that device used ThreadX rather than Linux/Unix, so the library
did not have other file functions, either.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 11 May 2021 03:20:16 GMT, Robert Riches <spamtrap42@jacob21819.net>
wrote:

>On 2021-05-10, MSB <Bit15_.us> wrote:
>> On Sun, 9 May 2021 21:41:44 +0000 (UTC), asdf <asdf@nospam.com> wrote:
>>
>>>On Fri, 07 May 2021 23:29:37 -0400, MSB wrote:
>>>
>>>> We have all sorts of handy string functions and a zillion other neat-o
>>>> things in the various libraries - but no fcopy().
>>>
>>>The reason is simpy that the vast majoity of the system C has
>>>been ported on don't even know what a file is, therefore it is
>>>not necessary to have it built in.
>>
>> Um ... disagree strongly. "Copy stuff" is an ultra-basic need.
>> Doesn't matter if it's CP/M or DOS or -ix .... most everything
>> DOES have a concept of a "file", or at least "block of binary
>> data on device".
>>
>> So, I see it as weird 'C' never dealt with this early on.
>>
>> Are K or R still alive ? Maybe we can ask.
>
>Your "most everything" does not include the EKG/ECG sensor unit I
>and a few other developers worked on several years ago. Okay,
>that device used threadX rather than Linux/Unix, so the library
>did not have other file functions, either.

I've writ a number of apps for micro-controllers, 8051/PIC, and
there's nothing higher-level unless YOU create it. Arduino
libraries are super-civilized by comparison - actually have
"files" and "devices" and such ... you can save files to an
FAT SD card or EEPROM or i2c-FRAM no problem.

But we're not talking PIC 12Fxxx ...

Even in the PDP-11 days there WERE "files" and you'd
want to copy/rename/delete/append.

So it's just a mystery why no standard fcopy() was
ever writ. It's not a critical issue, you can implement
a full-featured fcopy() in about 15-20 lines or so.
I'm just very CURIOUS. This seems to be a glaring
"hole" in the language. A "standard" function, like
"printf" or "fopen()" is generally a GOOD thing, gets
everyone on the same track instead of continually
re-inventing the wheel (with the inevitible little variations).

On Mon, 10 May 2021 13:29:34 +0200, "Carlos E.R."
<robin_listas@es.invalid> wrote:

>On 10/05/2021 06.43, MSB wrote:
>> On Sat, 08 May 2021 06:42:01 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> MSB <Bit15_.us> writes:
>>>
>>>> "C" has been around almost forever - I bought the K&R book
>>>> when it was new on the shelves WAY back when.
>>>>
>>>> We have all sorts of handy string functions and a zillion
>>>> other neat-o things in the various libraries - but no fcopy().
>>>> It seems so basic.
>>>>
>>>> Admittedly, it's not hard to write one - a "makedirs()"+
>>>> source&dest files (and better xfer all the stat() stuff) -
>>>> but, I guess it's a historical question, why was one never
>>>> included in stdio.h or a near relative ?
>>>
>>> It may seem basic, but how about needed?
>>> If something isn't needed why should someone create it?
>>
>> I would assert that "copy file" is SO basic and essential
>> that it should have been one of the first entries in some
>> standard library. We have rename(), we have remove(),
>> we have stat(). so why not fcopy() ???
>>
>> Basically every other decent language HAS its version
>> of fcopy(), usually with a lot of useful options. Not 'C'.
>
>Pascal doesn't. Not in the basic libraries, at least.

Um ... I seem to remember it being in Microsoft Pascal - and
that was a LONG time ago, some years before Turbo. Nick
understood the concept of a "file" ... and the things you'd need
to do with them. (Actually met Nick once ... but "correct"
structure was an obsession with him - leading to the great
disappointment of Modula - 'PC' destroying real-world
utility).

Wrote a Lazarus/FP app just the other week - STILL a good
language/RAD-Environment. Why waste tons of time with
Tk or GTK or QT or the others .... Lazarus/Delphi will give
you a WYSIWYG GUI with all the bells and whistles like
super-quick - fully compiled. Even works on a Pi.

Of course "raw" 'C' - no stdio.h or anything - is a pretty
stupid language too. However by the time K&R wrote
the book there were already a bunch of standard libraries.
Their most basic examples used printf().

>
>>
>> It's not a real impediment, just weird. A "hole" in the
>> overall paradigm. If it was intentional - I'm trying to
>> find out why.
>
>One reason would be that any function in the basic library was linked in
>the final code even if not used, making it bigger. There would be many
>other functions that also could be useful.

Wasn't long before compilers/linkers were smart enough
to drop "unused" references. And an fcopy() would have
been a relatively small bit of code to boot.

>Sometime in the 90's, I compared the sizes of "Hello world!" made with
>both Borland C and Borland Pascal. C version was 32 KB, BP was 3 KB.
>Borland Pascal used a non standard linking method that only included the
>code that was actually used in the program, producing much smaller code.

Turbo/Borland ... now Delphi/Lazarus ... was a HUGE improvement
over what was "usual" before.

TP2 was just *great* - and when TP3 came along I even found a
good use for the LOGO-ish "turtle" ... as a rotating wind arrow in
a weather app. Beat translating Foley/VanDam's "Fundamentals
of Interactive Computer Graphics" code :-)

Wrote big TP programs back then - big enough to require
the "overlay" functions on crappy 640k IBM-PCs (ok, not
as crappy as CP/M systems :-)

>I don't remember if the extended libraries of Borland Pascal or C, which
>allowed full text interfaces with mouse support and file browsing
>functions included a file copy function or not. Funny that you could
>edit text but not copy a file :-D

Mice came later - at least to the PC world. However you could
do most anything with text and keyboard - AND files. Don't
immediately remember an fcopy() for early TP .... mostly
you'd open a file and write data blocks - 90% like in 'C' now.

Anyway, I'm just curious - fcopy() is something OBVIOUS,
and thus a GAP, in 'C'. It's persistence in the modern world
is just so odd.

On Mon, 10 May 2021 14:19:13 -0000 (UTC), Rich <rich@example.invalid>
wrote:

>MSB <Bit15_.us> wrote:
>> On Sat, 08 May 2021 06:42:01 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>>MSB <Bit15_.us> writes:
>>>
>>>> "C" has been around almost forever - I bought the K&R book
>>>> when it was new on the shelves WAY back when.
>>>>
>>>> We have all sorts of handy string functions and a zillion
>>>> other neat-o things in the various libraries - but no fcopy().
>>>> It seems so basic.
>>>>
>>>> Admittedly, it's not hard to write one - a "makedirs()"+
>>>> source&dest files (and better xfer all the stat() stuff) -
>>>> but, I guess it's a historical question, why was one never
>>>> included in stdio.h or a near relative ?
>>>
>>>It may seem basic, but how about needed?
>>>If something isn't needed why should someone create it?
>>
>> I would assert that "copy file" is SO basic and essential
>> that it should have been one of the first entries in some
>> standard library. We have rename(),
>
>Rename is a syscall, which is why it is there.
>
>> we have remove(),
>
>Remove is also a syscall (unlink), which is also why it is in the
>library.
>
>> we have stat().
>
>Stat is ultimately another syscall, which is why it is also there.
>
>> so why not fcopy() ???
>
>There is no "fcopy" syscall. So no 'fcopy' in libc.

In Linux/Unix it's a "cp" or "mv" syscall. Didn't do
everything I wanted.

My curiosity has to do with "standardization". On the
whole it's a GOOD thing - gets everybody on the same
wavelength, so to speak. A standard fcopy() just seems
so OBVIOUS.

>> It's not a real impediment, just weird. A "hole" in the
>> overall paradigm. If it was intentional - I'm trying to
>> find out why.
>
>Most of the basic C libaries are more-or-less simply C level interfaces
>to the various Unix syscalls. As there is no "fcopy" syscall, there is
>no fcopy() function in the basic C libraries.

'C' is super-widely ported - microcontrollers on up. Unix is
merely ONE port of call. Really was barely even a Unix when
'C' was invented - much less with "B". There was barely any
concept of an OS then except on the Big Iron. Your A2/Commodore
and such didn't have an OS - just a bunch of little ROM/BIOS
library routines. Code excuted at address-0+<small-offset>
and that was that, basically like microcontrollers.

On 11/05/2021 05:44, MSB wrote:
>> Pascal doesn't. Not in the basic libraries, at least.
> Um ... I seem to remember it being in Microsoft Pascal

True pascal doesn't have any IO at all. As with any language designed by
an academic, it was completely useless for real world usage.

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

On 11/05/2021 06:05, MSB wrote:
> 'C' is super-widely ported - microcontrollers on up. Unix is
> merely ONE port of call. Really was barely even a Unix when
> 'C' was invented - much less with "B". T

Err, Unix was written in C, so there couldn't have been a Unix before C....

--
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 11/05/2021 06:05, MSB wrote:
>> 'C' is super-widely ported - microcontrollers on up. Unix is
>> merely ONE port of call. Really was barely even a Unix when
>> 'C' was invented - much less with "B". T
>
> Err, Unix was written in C, so there couldn't have been a Unix before C....

Unix predates C by several years. See https://www.tuhs.org/cgi-bin/utree.pl

--
https://www.greenend.org.uk/rjk/

MSB <Bit15_.us> wrote:
>>> so why not fcopy() ???
>>
>>There is no "fcopy" syscall. So no 'fcopy' in libc.
>
> In Linux/Unix it's a "cp" or "mv" syscall. Didn't do
> everything I wanted.

cp and mv are not syscalls. They are executables that you can use the
C system() function to execute.

syscalls are the actual function entry points provided by the kernel.

>>Most of the basic C libaries are more-or-less simply C level
>>interfaces to the various Unix syscalls. As there is no "fcopy"
>>syscall, there is no fcopy() function in the basic C libraries.
>
> 'C' is super-widely ported - microcontrollers on up. Unix is merely
> ONE port of call. Really was barely even a Unix when 'C' was
> invented - much less with "B".

Nope, you've got your history all wrong there. Unix came first. C was
invented to rewrite Unix from PDP assembly into a high level language
for porting Unix to another variant of the PDP series.

https://en.wikipedia.org/wiki/C_(programming_language)

A successor to the programming language B, C was originally
developed at Bell Labs by Dennis Ritchie between 1972 and 1973 to
construct utilities running on Unix. It was applied to
re-implementing the kernel of the Unix operating system.

...
The origin of C is closely tied to the development of the Unix
operating system, originally implemented in assembly language on a
PDP-7 by Dennis Ritchie and Ken Thompson, incorporating several
ideas from colleagues. Eventually, they decided to port the
operating system to a PDP-11. The original PDP-11 version of Unix
was also developed in assembly language.[6]

Thompson desired a programming language to make utilities for the
new platform. At first, he tried to make a Fortran compiler, but
soon gave up the idea. Instead, he created a cut-down version of
the recently developed BCPL systems programming language. The
official description of BCPL was not available at the time,[11] and
Thompson modified the syntax to be less wordy, producing the
similar but somewhat simpler B.[6] However, few utilities were
ultimately written in B because it was too slow, and B could not
take advantage of PDP-11 features such as byte addressability.

In 1972, Ritchie started to improve B, which resulted in creating a
new language C.[12] The C compiler and some utilities made with it
were included in Version 2 Unix.[13]

At Version 4 Unix, released in November 1973, the Unix kernel was
extensively re-implemented in C.[6] By this time, the C language
had acquired some powerful features such as struct types.

On 11/05/2021 09.11, The Natural Philosopher wrote:
> On 11/05/2021 05:44, MSB wrote:
>>> Pascal doesn't. Not in the basic libraries, at least.
>>    Um ... I seem to remember it being in Microsoft Pascal
>
> True pascal doesn't have any IO at all. As with any language designed by
> an academic, it was completely useless for real world usage.
>

True pascal of course had IO. Input, output, and files. You defined them
in the first line

program hello (output);

However, I have never seen "true" pascal. It doesn't exist.

With Turbo Pascal I did things like hanging from the timer interrupt and
play music in background as the the user played a game in the same
program, or writing a serial port terminal using the serial interrupt
for faster access than the commercial terminal I was given.

--
Cheers, Carlos.

MSB <Bit15_.us> wrote:
> So it's just a mystery why no standard fcopy() was
> ever writ. It's not a critical issue, you can implement
> a full-featured fcopy() in about 15-20 lines or so.
> I'm just very CURIOUS.

And, you answered your own question. When "you can implement a
full-featured fcopy() in about 15-20 lines or so" then that becomes a
candidate for "don't bother adding it to libc, it is trivial to
implement when/if someone wants it".

Remember, the Unix philosophy is small, single purpose tools, that
compose into larger tools. Libc provides all the necessary "small,
single purpose tools" for an fcopy(), so the "composition" of those
tools into a larger tool was left up to the end user.

> This seems to be a glaring "hole" in the language.

C the language is very minimal. Your complaint is actually "why do the
standard I/O libraries omit an fcopy() function".

> A "standard" function, like "printf" or "fopen()" is generally a
> GOOD thing, gets everyone on the same track instead of continually
> re-inventing the wheel (with the inevitible little variations).

And, in C the language, there is also no printf() and no fopen(). Both
of those are supplied by the libraries that accompany most
implementations of C the language.

Rich <rich@example.invalid> writes:
> MSB <Bit15_.us> wrote:
>> So it's just a mystery why no standard fcopy() was
>> ever writ. It's not a critical issue, you can implement
>> a full-featured fcopy() in about 15-20 lines or so.
>> I'm just very CURIOUS.
>
> And, you answered your own question. When "you can implement a
> full-featured fcopy() in about 15-20 lines or so" then that becomes a
> candidate for "don't bother adding it to libc, it is trivial to
> implement when/if someone wants it".

The C library is full of tiny functions, much smaller than that in their
V7 implementations, so the “no small functions” argument doesn’t work.

> Remember, the Unix philosophy is small, single purpose tools, that
> compose into larger tools. Libc provides all the necessary "small,
> single purpose tools" for an fcopy(), so the "composition" of those
> tools into a larger tool was left up to the end user.

There’s plenty of functions that are compositions of simpler ones, too,
e.g. putchar and getchar (you could use putc/getc instead), puts and
printf (use fprintf instead). So the “no compositions” argument doesn’t
work.

You seem to be trying to retroactively invent a rationale without
actually knowing what thought, if any, went into the original decision,
and without taking into account any counterexamples to your arguments.

Personally I think it’s more likely that it simply didn’t occur to
anyone (i.e. and the OP is wrong that it’s an obvious thing to include).

>> This seems to be a glaring "hole" in the language.
>
> C the language is very minimal. Your complaint is actually "why do the
> standard I/O libraries omit an fcopy() function".
>
>> A "standard" function, like "printf" or "fopen()" is generally a
>> GOOD thing, gets everyone on the same track instead of continually
>> re-inventing the wheel (with the inevitible little variations).
>
> And, in C the language, there is also no printf() and no fopen(). Both
> of those are supplied by the libraries that accompany most
> implementations of C the language.

The OP is obviously talking about hosted implementations, not
free-standing ones.

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell <invalid@invalid.invalid> wrote:
> Rich <rich@example.invalid> writes:
>> MSB <Bit15_.us> wrote:
>>> A "standard" function, like "printf" or "fopen()" is generally a
>>> GOOD thing, gets everyone on the same track instead of continually
>>> re-inventing the wheel (with the inevitible little variations).
>>
>> And, in C the language, there is also no printf() and no fopen().
>> Both of those are supplied by the libraries that accompany most
>> implementations of C the language.
>
> The OP is obviously talking about hosted implementations, not
> free-standing ones.

While the OP has 'drifted' in his subsequent posts into additionally
talking about hosted implementations, it is not at all obvious that was
their initial question's framework.

Their original was here:
Message-ID: <mg0c9ghgravcdi2cibr1l53fo1uqdm09lb@4ax.com>

And there is certainly nothing in that initial post that "obviously"
indicates they are talking about hosted implementations.

In any case, I'm beginning to believe the OP is actually trolling. If
they really had wanted an answer then comp.os.linux.misc is not the
correct group to ask, instead comp.lang.c would be where they would
properly ask this question.

On Fri, 07 May 2021 23:29:37 -0400, MSB wrote:

> "C" has been around almost forever - I bought the K&R book
> when it was new on the shelves WAY back when.
>
> We have all sorts of handy string functions and a zillion
> other neat-o things in the various libraries - but no fcopy().
> It seems so basic.

A verbatum file COPY function is easy enough to write, and of
limited use in most programs. It's not so "basic" a function that
it qualifies for inclusion in one of the standard libraries, although
you can probably find it implemented in /someone's/ library.

> Admittedly, it's not hard to write one - a "makedirs()"+
> source&dest files (and better xfer all the stat() stuff) -
> but, I guess it's a historical question, why was one never
> included in stdio.h or a near relative ?

Probably because Linux provides the POSIX-standard link(2)
and symlink(2) system calls instead. And, Linux /also/ provides
the sendfile(2) system call that automagically copies files (albeit,
after some requisite application program preparation).

HTH
--
Lew Pitcher
"In Skills, We Trust"