On Tue, 11 May 2021 08:12:52 +0100, The Natural Philosopher wrote:

> 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....

Err... Unix was /originally/ written in GECOS on a GE (later Honeywell) 635
system (https://www.bell-labs.com/usr/dmr/www/hist.html)

Later, once this seminal Unix had become self-sustaining (with the port of
the Assembler), the Bell Labs team (Kernighan, Ritchie, et al) created the
Unix implementation of the C language from it's B and BCPL roots, then
/re-implemented/ Unix with C (See "The C Progrmming Language" Brian W. Kernighan
& Dennis M. Ritchie, 1978, Preface: "C was originally designed for and implemented
on the UNIX operating system on the DEC PDP-11, by Dennis Ritchie")

So, you see, there most definitely /was/ a UNIX before C.

--
Lew Pitcher
"In Skills, We Trust"

On Tue, 11 May 2021 19:20:26 +0000, Lew Pitcher wrote:

> 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).

A trivial file copy program that uses sendfile(2):

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/sendfile.h>

int main(int argc, char *argv[])
{
int in_fd, out_fd;
struct stat in_stat;

if (argc != 3) return EXIT_FAILURE; /* missing filenames */
if ((in_fd = open(argv[1],O_RDONLY)) == -1) return EXIT_FAILURE; /* cant open input file */
if (fstat(in_fd,&in_stat)) return EXIT_FAILURE; /* cant stat input file */
if ((out_fd = creat(argv[2],0666)) == -1) return EXIT_FAILURE; /* cant create output file */

sendfile(out_fd,in_fd,NULL,in_stat.st_size); /* the OP's fcopy() function...ish */

close(out_fd);
close(in_fd);
return EXIT_SUCCESS;
}

--
Lew Pitcher
"In Skills, We Trust"

On Mon, 10 May 2021 00:48:21 -0400, MSB wrote:

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

Ken Thompson (the designer and original implementor of Unix) is still alive,
as is Brian Kernighan. Dennis Ritchie (the designer of the C language, and
implementor of Unix-written-in-C), sadly, passed away in 2011.

--
Lew Pitcher
"In Skills, We Trust"

On Tue, 11 May 2021 19:51:16 +0000, Lew Pitcher wrote:

> On Tue, 11 May 2021 19:20:26 +0000, Lew Pitcher wrote:
>
>> 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).
>
> A trivial file copy program that uses sendfile(2):
[snip]

/The/ trivial file copy program from K&R v1 ("The C Programming Language", 1978)

main() /* copy input to output; 2nd version */
{
int c;
while ((c = getchar()) != EOF)
putchar(c);
}

--
Lew Pitcher
"In Skills, We Trust"

At Tue, 11 May 2021 20:07:49 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

>
> On Tue, 11 May 2021 19:51:16 +0000, Lew Pitcher wrote:
>
> > On Tue, 11 May 2021 19:20:26 +0000, Lew Pitcher wrote:
> >
> >> 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).
> >
> > A trivial file copy program that uses sendfile(2):
> [snip]
>
> /The/ trivial file copy program from K&R v1 ("The C Programming Language", 1978)
>
> main() /* copy input to output; 2nd version */
> {
> int c;
> while ((c = getchar()) != EOF)
> putchar(c);
> }

Ha. stdin to stdout, one byte at a time.... Probably very slow...

>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

Correction.....

On Tue, 11 May 2021 19:32:35 +0000, Lew Pitcher wrote:

> On Tue, 11 May 2021 08:12:52 +0100, The Natural Philosopher wrote:
>
>> 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....
>
> Err... Unix was /originally/ written in
PDP-7 assembly language, cross-assembled in
> GECOS on a GE (later Honeywell) 635
> system (https://www.bell-labs.com/usr/dmr/www/hist.html)
>
> Later, once this seminal Unix had become self-sustaining (with the port of
> the Assembler), the Bell Labs team (Kernighan, Ritchie, et al) created the
> Unix implementation of the C language from it's B and BCPL roots, then
> /re-implemented/ Unix with C (See "The C Progrmming Language" Brian W. Kernighan
> & Dennis M. Ritchie, 1978, Preface: "C was originally designed for and implemented
> on the UNIX operating system on the DEC PDP-11, by Dennis Ritchie")
>
> So, you see, there most definitely /was/ a UNIX before C.

--
Lew Pitcher
"In Skills, We Trust"

On Tue, 11 May 2021 16:00:07 -0500, Robert Heller wrote:

> At Tue, 11 May 2021 20:07:49 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>
>>
>> On Tue, 11 May 2021 19:51:16 +0000, Lew Pitcher wrote:
>>
>> > On Tue, 11 May 2021 19:20:26 +0000, Lew Pitcher wrote:
>> >
>> >> 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).
>> >
>> > A trivial file copy program that uses sendfile(2):
>> [snip]
>>
>> /The/ trivial file copy program from K&R v1 ("The C Programming Language", 1978)
>>
>> main() /* copy input to output; 2nd version */
>> {
>> int c;
>> while ((c = getchar()) != EOF)
>> putchar(c);
>> }
>
> Ha. stdin to stdout, one byte at a time.... Probably very slow...

Probably not as slow as you think.

Yes, byte-at-a-time transfer from kernel buffer to program space,
followed by byte-at-a-time from program space to kernel buffer would
have taken a bit of time (compared to kernel-buffer I/O), but the
kernel would have spent much more time waiting for it's block I/O to
complete than would have been taken by kernel to application to kernel
data transfer.

--
Lew Pitcher
"In Skills, We Trust"

At Tue, 11 May 2021 21:27:41 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

>
> On Tue, 11 May 2021 16:00:07 -0500, Robert Heller wrote:
>
> > At Tue, 11 May 2021 20:07:49 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> >
> >>
> >> On Tue, 11 May 2021 19:51:16 +0000, Lew Pitcher wrote:
> >>
> >> > On Tue, 11 May 2021 19:20:26 +0000, Lew Pitcher wrote:
> >> >
> >> >> 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).
> >> >
> >> > A trivial file copy program that uses sendfile(2):
> >> [snip]
> >>
> >> /The/ trivial file copy program from K&R v1 ("The C Programming Language", 1978)
> >>
> >> main() /* copy input to output; 2nd version */
> >> {
> >> int c;
> >> while ((c = getchar()) != EOF)
> >> putchar(c);
> >> }
> >
> > Ha. stdin to stdout, one byte at a time.... Probably very slow...
>
> Probably not as slow as you think.
>
> Yes, byte-at-a-time transfer from kernel buffer to program space,
> followed by byte-at-a-time from program space to kernel buffer would
> have taken a bit of time (compared to kernel-buffer I/O), but the
> kernel would have spent much more time waiting for it's block I/O to
> complete than would have been taken by kernel to application to kernel
> data transfer.

I was think more in terms of function call overhead. But, yeah, probably not
really all that noticable...

>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On 2021-05-11, Robert Heller <heller@deepsoft.com> wrote:
> At Tue, 11 May 2021 21:27:41 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>
>>
>> On Tue, 11 May 2021 16:00:07 -0500, Robert Heller wrote:
>>
>> > At Tue, 11 May 2021 20:07:49 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> >
>> >>
>> >> On Tue, 11 May 2021 19:51:16 +0000, Lew Pitcher wrote:
>> >>
>> >> > On Tue, 11 May 2021 19:20:26 +0000, Lew Pitcher wrote:
>> >> >
>> >> >> 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).
>> >> >
>> >> > A trivial file copy program that uses sendfile(2):
>> >> [snip]
>> >>
>> >> /The/ trivial file copy program from K&R v1 ("The C Programming Language", 1978)
>> >>
>> >> main() /* copy input to output; 2nd version */
>> >> {
>> >> int c;
>> >> while ((c = getchar()) != EOF)
>> >> putchar(c);
>> >> }
>> >
>> > Ha. stdin to stdout, one byte at a time.... Probably very slow...
>>
>> Probably not as slow as you think.
>>
>> Yes, byte-at-a-time transfer from kernel buffer to program space,
>> followed by byte-at-a-time from program space to kernel buffer would
>> have taken a bit of time (compared to kernel-buffer I/O), but the
>> kernel would have spent much more time waiting for it's block I/O to
>> complete than would have been taken by kernel to application to kernel
>> data transfer.
>
> I was think more in terms of function call overhead. But, yeah, probably not
> really all that noticable...

In at least some cases, putc(), getc(), putchar(), and getchar()
were macros--according to K&R's "The C Programming Language" with
a 1978 copyright date.

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

On Tue, 11 May 2021 08:12:52 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

>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....

Nor a "C" before Unix ? :-)

Unix CAME to be written mostly in 'C' because, well, it
was good for the job. It's origins however were rather
more diverse. They were SELLING it after all - and the
rule is "function first, form later".

On 11.05.2021 at 23:18, MSB scribbled:

> On Tue, 11 May 2021 08:12:52 +0100, The Natural Philosopher
> <tnp@invalid.invalid> wrote:
>
> >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....
>
> Nor a "C" before Unix ? :-)
>
> Unix CAME to be written mostly in 'C' because, well, it
> was good for the job. It's origins however were rather
> more diverse. They were SELLING it after all - and the
> rule is "function first, form later".

The original Unix was written in assembler on an until then unused
PDP-7 sitting in a corner at AT&T Bell Labs in 1969. Dennis Ritchie
created the C language — as a compiled and improved successor to Ken
Thompson's interpreted B language — in 1973. It was only at that time
that Unix was rewritten in C so as to make it portable, and this was on
a PDP-11.

In addition to this, AT&T Bell Labs could not sell/market Unix at the
time due to an antitrust ruling, and they were obligated to license the
source code to whoever requested it. That's how BSD got involved.

--
With respect,
= Aragorn

On Tue, 11 May 2021 11:58:41 -0000 (UTC), Rich <rich@example.invalid>
wrote:

>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.

Technically true. However you won't find a terminal emulator
without 'cp' in some form or another. If not stricty 'kernel' it
is still a core function. NO sort of OS/system is going to be
without a handy fcopy()-like command.

>>>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.

Correct. First there was Unix (v0.x) which was a concept, but
one kind of cobbled-together in a variety of ways. When 'C'
arrived, got good, they realized it was just ideal to re-write
all the junky bits in 'C'. It was better than assembly which
would have to be ported between diverse archetectures.
Just port 'C' and recompile your UNIX system.

>
>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.

'B' does not look a lot like 'C' superficially. However it WAS
still better than the abovementioned custom assember for
every box. Fortunately, Ritchie got inspired .... cut and buffed
the raw diamond hidden in 'B'. Fifty years later it's STILL
What You Use to write decent kernels and all the core
utilities. Will be for a few more decades very likely. AI
type systems will eventually require 'C' to be displaced,
the 'OS' writ in and by the AI "language" sort of like PICK-OS
came to be writ in PICK.

> ...
>
> 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.

I was looking at 'D' today .... SOME improvements over 'C'/CPP, but
also some annoyances. Is it worth it ?

I was also looking at Modula-2 ... did you know there are at least
three sets of libraries for it - ISO, PIM and LOGITECH, plus the
libraries GNU-GM2 put together ? What a mess. Could barely
figure out how to get anything more than "Hello World" to compile.
Somehow, I don't think I'd be tempted to write an OS in M-2.

On Tue, 11 May 2021 21:13:48 -0000 (UTC), Lew Pitcher
<lew.pitcher@digitalfreehold.ca> wrote:

>Correction.....
>
>On Tue, 11 May 2021 19:32:35 +0000, Lew Pitcher wrote:
>
>> On Tue, 11 May 2021 08:12:52 +0100, The Natural Philosopher wrote:
>>
>>> 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....
>>
>> Err... Unix was /originally/ written in
>PDP-7 assembly language, cross-assembled in
>> GECOS on a GE (later Honeywell) 635
>> system (https://www.bell-labs.com/usr/dmr/www/hist.html)
>>
>> Later, once this seminal Unix had become self-sustaining (with the port of
>> the Assembler), the Bell Labs team (Kernighan, Ritchie, et al) created the
>> Unix implementation of the C language from it's B and BCPL roots, then
>> /re-implemented/ Unix with C (See "The C Progrmming Language" Brian W. Kernighan
>> & Dennis M. Ritchie, 1978, Preface: "C was originally designed for and implemented
>> on the UNIX operating system on the DEC PDP-11, by Dennis Ritchie")
>>
>> So, you see, there most definitely /was/ a UNIX before C.

Some people these days have a rather "creationist" notion
of UNIX ... that the concept and impementation (and 'C')
just kind of sprang into existence in a burst of purple
magic smoke. All those things co-evolved over a number
of years. 'C' finally emerged as the best and obvious way
to write the kernel and core utilities - and still is - but when
UNIX started there was no 'C'. Desired FUNCTION first,
standardization and polish later.

VMS was another Damned Good OS and it *could* have
been the worlds UNIX. However DEC was a little too
aggressive about its intellectual property IMHO, and failed
to grasp the importance of giving universities the breaks
required in order to cultivate a larger future following.

On 12 May 2021 02:44:52 GMT, Robert Riches <spamtrap42@jacob21819.net>
wrote:

>On 2021-05-11, Robert Heller <heller@deepsoft.com> wrote:
>> At Tue, 11 May 2021 21:27:41 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>
>>>
>>> On Tue, 11 May 2021 16:00:07 -0500, Robert Heller wrote:
>>>
>>> > At Tue, 11 May 2021 20:07:49 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>> >
>>> >>
>>> >> On Tue, 11 May 2021 19:51:16 +0000, Lew Pitcher wrote:
>>> >>
>>> >> > On Tue, 11 May 2021 19:20:26 +0000, Lew Pitcher wrote:
>>> >> >
>>> >> >> 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).
>>> >> >
>>> >> > A trivial file copy program that uses sendfile(2):
>>> >> [snip]
>>> >>
>>> >> /The/ trivial file copy program from K&R v1 ("The C Programming Language", 1978)
>>> >>
>>> >> main() /* copy input to output; 2nd version */
>>> >> {
>>> >> int c;
>>> >> while ((c = getchar()) != EOF)
>>> >> putchar(c);
>>> >> }
>>> >
>>> > Ha. stdin to stdout, one byte at a time.... Probably very slow...
>>>
>>> Probably not as slow as you think.
>>>
>>> Yes, byte-at-a-time transfer from kernel buffer to program space,
>>> followed by byte-at-a-time from program space to kernel buffer would
>>> have taken a bit of time (compared to kernel-buffer I/O), but the
>>> kernel would have spent much more time waiting for it's block I/O to
>>> complete than would have been taken by kernel to application to kernel
>>> data transfer.
>>
>> I was think more in terms of function call overhead. But, yeah, probably not
>> really all that noticable...
>
>In at least some cases, putc(), getc(), putchar(), and getchar()
>were macros--according to K&R's "The C Programming Language" with
>a 1978 copyright date.

I think they still are in some of the bargain-basement 'C'
implementations for microcontrollers. Still, something SO
basic and common, just write the damned function outright
and stuff it into a .h along with 100 other often-unused
functions ! At least it would be STANDARD.

Recently I re-invented the wheel yet again, writing an
fcopy(). I spent some time wondering whether to use
open/write/close -vs- fopen/fwrite/fclose. I shouldn't
have had to waste the time. They are NOT quite
the same ... fwrite() can sometimes try to "fix"
line endings - assuming you're writing text instead
of binary. I eventually settled on open/write/close
instead just because of that possibility. Just a dozen
lines - a few dedicated to immediate bail-out if the
caller screwed up and sent garbage params ( I like
to cover Stupid Users and send useful error codes
when they screw up).

Geez ... my little inquiry seems to have gotten out of
hand. I assumed there'd be somebody a bit before
my time who could clearly explain why no standard
fcopy() was in 'C'. Instead ............. :-)

On Tue, 11 May 2021 13:58:17 +0200, "Carlos E.R."
<robin_listas@es.invalid> wrote:

>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.

I tend to agree. Perhaps he's talking about some
alpha version Wirth hadn't fully fleshed out yet.

>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.

Hey ! That's about what I first used it for ... though no
music - app was for a digitizing tablet for serious govt
types, No Fun Allowed.

You could do the serial interrrupt thing in BASICA too,
FAR better if you compiled it with BASCOM. However
when TP came out I rewrote my BASICA apps.

On Tue, 11 May 2021 20:04:31 -0000 (UTC), Lew Pitcher
<lew.pitcher@digitalfreehold.ca> wrote:

>On Mon, 10 May 2021 00:48:21 -0400, MSB wrote:
>
>> Are K or R still alive ? Maybe we can ask.
>
>Ken Thompson (the designer and original implementor of Unix) is still alive,
>as is Brian Kernighan. Dennis Ritchie (the designer of the C language, and
>implementor of Unix-written-in-C), sadly, passed away in 2011.

I think of K&R sort of like Spielberg and Lucas or Jobs & Woz.
Each brought their talents and perspective and the synthesis
was greater than the parts.

Alas R would have been the one to ask about THIS simple
little question - which seems to have gotten out of hand.

I wonder what will eventually replace 'C' ? AI systems are
mostly 'C' under the hood, now, but eventually I see the
underlying system being composed in and by the larger
AI system. This is not unprecedented, PICK-OS started
mostly as 'C', but quickly it was its own beginning and
end - PICK written in PICK.

I miss PICK ... sure, IBM and a few others will sell you
what's essentially a PICK-OS/MV-DB ... but the price
is a killer. (still think the MV model is best for most
real-world data though)

Rich <rich@example.invalid> writes:
> 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.

Now you’re just being silly. Hosted implementations have IO and
free-standing implementations don’t (indeed they barely have a libc at
all), so yes, it is obvious that he was talking about hosted
implementations.

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

MSB <Bit15_.us> wrote:
> On Tue, 11 May 2021 13:58:17 +0200, "Carlos E.R."
> <robin_listas@es.invalid> wrote:
>
>>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.
>
> I tend to agree. Perhaps he's talking about some
> alpha version Wirth hadn't fully fleshed out yet.

No, he is talking about Wirth's actual Pascal (which Wirth never
intended to build a compiler for). Wirth designed it to use in classes
without ever being compiled/interpreted (other than by a human grader).
So it never needed input/output, because it was never intended (by
Wirth) to be compiled/interpreted (other than by a human grading
assignments).

MSB <Bit15_.us> wrote:
> Geez ... my little inquiry seems to have gotten out of hand. I
> assumed there'd be somebody a bit before my time who could clearly
> explain why no standard fcopy() was in 'C'. Instead .............
> :-)

Yes, your trolling has been /loads of fun/...

If you genuinely wanted an answer, and were really looking for folks
who would likely know, you'd have posted to 'comp.lang.c'. Posting
here, in the wrong group for that question, looks very trollish.

But, given the length of time that has passed with no file copy
function having been added to the basic C I/O library, the "obvious"
answer is that having one must not have been as "obvious" to everyone
who had a hand in creating C's I/O library than you feel it is now.

When years go by, with huge popularity and usage by many very capable
programmers over those years, and a file copy function is still not
there, that then suggests that none of those greats found a need
suffient to cause them to make the addition or suggest the addition to
those maintaining the library. I.e., the fact that those programmers,
far better than yourself, never found a need weighs heavily in favor of
it not being as obvious a need as you believe.

On 12/05/2021 15.11, Rich wrote:
> MSB <Bit15_.us> wrote:
>> On Tue, 11 May 2021 13:58:17 +0200, "Carlos E.R."
>> <robin_listas@es.invalid> wrote:
>>
>>> 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.
>>
>> I tend to agree. Perhaps he's talking about some
>> alpha version Wirth hadn't fully fleshed out yet.
>
> No, he is talking about Wirth's actual Pascal (which Wirth never
> intended to build a compiler for). Wirth designed it to use in classes
> without ever being compiled/interpreted (other than by a human grader).
> So it never needed input/output, because it was never intended (by
> Wirth) to be compiled/interpreted (other than by a human grading
> assignments).
>

Define what you mean by input/output.

Because the first line of a program as designed by Wirth was:

program something(input, output);

So indeed it had input/output.

--
Cheers, Carlos.

On 12.5.21 16.11, Rich wrote:
> MSB <Bit15_.us> wrote:
>> On Tue, 11 May 2021 13:58:17 +0200, "Carlos E.R."
>> <robin_listas@es.invalid> wrote:
>>
>>> 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.
>>
>> I tend to agree. Perhaps he's talking about some
>> alpha version Wirth hadn't fully fleshed out yet.
>
> No, he is talking about Wirth's actual Pascal (which Wirth never
> intended to build a compiler for). Wirth designed it to use in classes
> without ever being compiled/interpreted (other than by a human grader).
> So it never needed input/output, because it was never intended (by
> Wirth) to be compiled/interpreted (other than by a human grading
> assignments).

Three Wirth's students, Urs Ammann, Kesav Nori and Christian Jacobi
wrote the first Pascal compiler - in Pascal.

I may still have its listings somewhere.

--

-TV

Rich <rich@example.invalid> writes:
> No, he is talking about Wirth's actual Pascal (which Wirth never
> intended to build a compiler for). Wirth designed it to use in classes
> without ever being compiled/interpreted (other than by a human grader).
> So it never needed input/output, because it was never intended (by
> Wirth) to be compiled/interpreted (other than by a human grading
> assignments).

Over here in reality, Wirth knew perfectly well that a language without
an implementation would be totally pointless. He intended to build a
compiler for it and indeed did so.

It is never sufficient to merely postulate a language on paper. A solid
compiler also had to be built, which usually was a highly complex
program. In this respect, large industrial firms had an advantage over
our Working Group, which had to rely on enthusiasts at universities. I
left the Group in 1966 and devoted myself together with a few doctoral
students at Stanford University to the construction of a compiler for my
proposal.

The result was the language Algol W,2 which after 1967 came into use
at many locations on large IBM computers. It became quite
successful. The milestone Algol 68 did appear and then sank quickly
into obscurity under its own weight, although a few of its concepts
did survive into subsequent languages.

But in my opinion Algol W was not perfectly satisfactory. It still
contained too many compromises, having emerged from a committee. After
my return to Switzerland, I designed a language after my own
preferences: Pascal. Together with a few assistants, we wrote a user
manual and constructed a compiler.

https://cacm.acm.org/magazines/2021/3/250705-50-years-of-pascal/fulltext

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

MSB 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.

No, those are programs (binaries) or shell built-ins. Not syscalls.

> 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.

Not to me or anybody else who is answering this thread.

>>> It's not a real impediment, just weird. A "hole" in the
>>> overall paradigm.

Name a single function in the C standard library that is remotely as complex
and as implementation-dependent as your proposed fcopy(). Better yet, name a
bunch of them so we can see the "hole" better.

I believe you don't understand the paradigm.

--
robert

MSB wrote:
> Technically true. However you won't find a terminal emulator
> without 'cp' in some form or another.

Your terminal emulator is interacting with a program called a "shell" in Unix
(similar concepts exist on other OSes). This shell has either a built-in "cp"
program, or it calls a binary that does the copying.

> If not stricty 'kernel' it
> is still a core function. NO sort of OS/system is going to be
> without a handy fcopy()-like command.

Then just use that. It really doesn't belong in the core library of any
universal programming language.

--
robert

MSB wrote:
> Recently I re-invented the wheel yet again, writing an
> fcopy(). I spent some time wondering whether to use
> open/write/close -vs- fopen/fwrite/fclose. I shouldn't
> have had to waste the time.

You just answered your own question. If you had an idea of how a standardized
fcopy() should work you'd have written it ONCE a long time ago and just used it
in your projects. The fact that you keep re-writing it shows that there is no
one answer to this problem.

> They are NOT quite
> the same ... fwrite() can sometimes try to "fix"
> line endings - assuming you're writing text instead
> of binary. I eventually settled on open/write/close
> instead just because of that possibility. Just a dozen
> lines - a few dedicated to immediate bail-out if the
> caller screwed up and sent garbage params ( I like
> to cover Stupid Users and send useful error codes
> when they screw up).

Next guy needs raw speed and has pre-verified data and doesn't want your
fcopy() to waste time on checks. Next guy wants to copy between open file
handles.

--
robert