On 12/05/2021 14: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).
>
yes.
And I/O destroyed the integrity of its academic correctness.

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

H.L. Mencken, A Mencken Chrestomathy

On 12.5.21 18.49, Robert Latest wrote:
> 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.

For simple copy we have cp, and for brute-force copy there is dd.

--

-TV

On Tue, 11 May 2021 23:49:05 -0400, MSB wrote:

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

You seem to be confused.

A "terminal emulator" is one form of application program. Typically, such
a program provides an input/output conduit to /other/ application programs
(such as shells or text-editors or anything else that needs a keyboard input
and/or a character output). Terminal emulators /rarely/ have file copy support
built in.

"cp" is another form of application program. It's purpose is to make duplicates
of existing files. As an application program, it can be invoked by other application
programs (like shells, text-editors, etc.) through standard system calls.

Your asked-for fcopy() would be a function; a code fragment compiled into a linkable
object to be included in an application program. There are not many application
programs that /require/ a file-copy facility, and the function is trivial to write,
making it a poor candidate for standardization.

sendfile() is both a standard (in Linux) library function /and/ a system call; the
system call does the actual work, and the library function sanity-checks the
input parameters. sendfile() performs a file-to-file data copy, given two open file
descriptors.

See the hierarchy?
Terminal Emulator
Shell
cp
fcopy
sendfile()

Of these, the /only/ kernel component is the syscall part of the sendfile() standard
function.

(For sendfile(), you can substitute read()/write() if you wish).

And, bye the way, you moved the goalposts again.

You wanted to know why there was no standard library fcopy() /function/.
Now your point seems to be about a /command/ (an application program).
Well, Unix /has/ a /command/ that does fcopy; it is called cp(1)

[snip]
--
Lew Pitcher
"In Skills, We Trust"

Robert Latest <boblatest@yahoo.com> writes:
> MSB wrote:
>>>> 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.

There are many. printf and scanf are full of complexity even ignoring
the IO layer. Locale handling is pretty complex. Memory management is
complex (glibc’s malloc.c is nearly 6KLOC). Most of math.h is pretty
hairy if you don’t have floating point instructions and the rest even if
you do. multibyte<->wchar conversion can easily get complicated.

The theory that only simple functions got into the standard C library
doesn’t survive contact with reality. As for implementation dependence,
platform-dependent elements to a common activity are an argument _in
favour_ of standardization, not against. e.g. the kernel-level details
of IO are very platform-dependent, so having a common IO abstraction in
the language’s runtime library is useful.

I don’t understand why people are coming up with such nonsensical
retroactive justifications, and not even doing cursory checks to see if
they make any sense.

The reality is, probably, simply that nobody thought it very important.

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

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Tue, 11 May 2021 23:49:05 -0400, MSB wrote:
>> 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.
>
> You seem to be confused.

MSB seems to be *very* confused - or else MSB is doing a good job
trolling. I'm starting to believe MSB has been trolling this whole
time.

> And, bye the way, you moved the goalposts again.
>
> You wanted to know why there was no standard library fcopy() /function/.
> Now your point seems to be about a /command/ (an application program).
> Well, Unix /has/ a /command/ that does fcopy; it is called cp(1)

More evidence that MSB is trolling.

In comp.os.linux.misc, Rich <rich@example.invalid> wrote:
> 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.

Nah, this is off-topic in comp.lang.c, which isn't about "what functions
are in your libraries?" but "how does C work?" eg, understanding the
limits of specified behavior.

There probably is a better group than c.o.l.misc, but this doesn't seem
_entirely_ wrong for asking about Linux library functions.

Elijah
------
also off-topic in c.l.c: bogus solutions to the halting problem

In comp.os.linux.misc, Rich <rich@example.invalid> wrote:
> 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.

As with Richard Kettlewell in another reply, I don't buy that. Let's
consider a real example.

ex version 1.1 (the first one to have a "vi"sual mode), was written
before system() was in a standard library, so it implements it itself:

invoked:
https://github.com/n-t-roff/ex-1.1/blob/master/ex_unix.c#L82

actual code:
https://github.com/n-t-roff/ex-1.1/blob/master/ex_unix.c#L105

The functions in that file do some other stuff, but the part that is
system() is just a few lines of code. And I really believe if system()
were available, Joy would have just done those things in a wrap of
system().

Yet even though it is so easy to implement, at some point system()
_was_ written and now it is a standard part of the library. Why not a
file copy function?

I think the reason is just plain copying a file, as opposed to doing
some transformation on a file, is a very rare task in programs. Users
copy files for backup, "installing", as a first step towards modifying.
Programs create new, different, files, and don't typically have a use
for unadulterated copying. Other than the "install" use case, I can't
think of the need for copying, and install has usually been done in
shell scripting, where we have `cp`.

I hear someone starting to object "but backups are copies". And there
are programs that do use ${original}.bak or ${original}~ backup files.
I have not examined all such cases, but the ones I have the backup is
not implemented with a copy() function. Instead it is a rename and
recreate, done when there are changes. The inode, which stays the same
for a rename, shows that the backup is the original file, and the
new file has the original name. This is the "doing some transformation"
thing just slightly obfuscated.

Elijah
------
has also seen popen() implemented in a few lines inside old code

On Wed, 12 May 2021 13:20:47 -0000 (UTC), Rich <rich@example.invalid>
wrote:

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

Sorry, but I almost exclusively use Linux and it's
written amost entirely in 'C' .... so this ISN'T a
stupid place to ask the question.

My next question is why you think I'm "trolling". It
was a perfectly legit historical question. I thought
there'd be ONE clear answer ... but no ......

On 12 May 2021 15:49:08 GMT, Robert Latest <boblatest@yahoo.com>
wrote:

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

But then I'd have to go back over about 40 years of
old projects .....

Easier/funner to just re-write.

Besides, every project is a little different. For quite awhile
I was dealing with mass quantities of ASCII records ... and
fread()/fwrite() was appropriate - saved a few steps.

But THIS project, lots of binary files included in the mix.

So, a re-think, a few extra embellishments that fit the
task at hand .......

I'd think you'd understand that.

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

Actually, I benchmarked fopen/fread/fwrite -vs- open/read/write and,
at least on my current box, there was no significant difference -
using a 4k xfer buffer.

As for the "next guy", he/she can write their OWN for
all I care. I've never worked in a cubicle-farm with a bunch
of Dilberts. I do like to leave "decent" heavily-commented
templates though, a touch of "legacy" I suppose.

Besides, with 'C', all the time is wasted in I/O ... so
there really isn't much in the way of "faster". NAS
or local drive - they only xfer data just SO fast. When
they come out with SATA-64k *then* .... :-)

On Wed, 12 May 2021 19:54:01 +0300, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:

>On 12.5.21 18.49, Robert Latest wrote:
>> 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.
>
>
>For simple copy we have cp, and for brute-force copy there is dd.

Most of the time I *do* just "cheap out" with system("cp ....").
It's easy, it works - albeit a bit ugly and "un-C".

I did find that "mv" doesn't always get it right ... if a filename
includes weirdo characters. "File ~$$$ Stuff.doc" can be
translated as an escape sequence no matter whether
you put quotes around the mess or not. 'C' rename()
works right every time though. In this case I was emulating
rsync's "--delete" option ... but with backup files that had been
changed so the names/sizes/etc weren't quite the same
as the originals. If you have a 3-digit IQ you NEVER *EVER*
put stuff on 'cloud' storage without first heavily encrypting
it all - "We Keep Your Data Safe" ... yea, sure ......... I wrote
a whole callable 'c' app to deal with THAT lie.

So, if rename(), why not a standard fcopy() with a few
useful options too ? If the Linux clique isn't sure I guess
we'll never know for sure. I've been informed that Ritchie
is deceased ......

'dd' - "Disk Destroyer :-)" does have its uses - but not in
anything I've done recently.

On Wed, 12 May 2021 22:18:39 -0000 (UTC), Rich <rich@example.invalid>
wrote:

>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Tue, 11 May 2021 23:49:05 -0400, MSB wrote:
>>> 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.
>>
>> You seem to be confused.
>
>MSB seems to be *very* confused - or else MSB is doing a good job
>trolling. I'm starting to believe MSB has been trolling this whole
>time.

Too much COVID lockdown time I suspect :-)

Next you'll begin believing 'Q' conspiracy theories ...
after that it's living in a sewer drain wearing a
tinfoil hat so "They" can't get to you .........

Meanwhile, let's try to keep things civil.

From WHERE comes 'cp' ? It is not strictly 'kernel'
but it's a standard, core, utility. NO system is complete
without it in some shape or form. A VIC-20 had it. ZX-81
as well. Ah ...audio cassette 'drives' .......

With microcontrollers you may have to write your own
alas ... fun with RAM often measured in bytes and
no such concept as a "storage device".

They don't make the PIC 16F84 (or 16C84JW before that)
anymore but it should be fun to look into looking into how
you make files/directories on I2C FRAMs/EEPROM/SD
using naught but assember. Coding that willl give you a buzz,
puts the FUN back in computing :-)

On 13/05/2021 05:52, MSB wrote:
> They don't make the PIC 16F84 (or 16C84JW before that)
> anymore but it should be fun to look into looking into how
> you make files/directories on I2C FRAMs/EEPROM/SD
> using naught but assember. Coding that willl give you a buzz,
> puts the FUN back in computing

I certainly wrote assembler to access a dos formatted disk drive on an
8086 single board computer. And most of a libc too...

--
“The ultimate result of shielding men from the effects of folly is to
fill the world with fools.”

Herbert Spencer

MSB <Bit15_.us> wrote:
> On Wed, 12 May 2021 22:18:39 -0000 (UTC), Rich <rich@example.invalid>
> wrote:
>
>>Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>> On Tue, 11 May 2021 23:49:05 -0400, MSB wrote:
>>>> 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.
>>>
>>> You seem to be confused.
>>
>>MSB seems to be *very* confused - or else MSB is doing a good job
>>trolling. I'm starting to believe MSB has been trolling this whole
>>time.
>
> From WHERE comes 'cp' ? It is not strictly 'kernel'
> but it's a standard, core, utility.

A bit of asking google or duckduckgo would answer these most basic
questions of yours, and remove some of your confusion.

For Linux distributions, 'cp' is from the GNU Core Utilities package:

https://en.wikipedia.org/wiki/GNU_Core_Utilities

It is just a binary executable, usually residing at /bin/cp on disk.

If you want to see the C implementation, then download and examine the
source for a version of the GNU Core Utilities (you can find where to
download by again asking a search engine).

MSB <Bit15_.us> wrote:
> On Wed, 12 May 2021 13:20:47 -0000 (UTC), Rich <rich@example.invalid>
> wrote:
>
>>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.
>
> Sorry, but I almost exclusively use Linux and it's
> written amost entirely in 'C' .... so this ISN'T a
> stupid place to ask the question.

Other than C's libc, and the group of functions provided therein, were
more or less standardized long before Linux existed. Linux may be
mostly written in C, but that does not mean the authors of Linux also
wrote the C compiler or the C library functions. There may be some
crossover between the two, but gcc (the C compiler from GNU) and
gnulibc (the C libraries, also from GNU) both existed before Linux.

> My next question is why you think I'm "trolling". It
> was a perfectly legit historical question. I thought
> there'd be ONE clear answer ... but no ......

Your initial post did not look like a troll. But your subsequent goal
post shifting, revisionist history, feigning confusion, and
argumentative posts look very trollish.

MSB <Bit15_.us> wrote:
> On Wed, 12 May 2021 19:54:01 +0300, Tauno Voipio
>>For simple copy we have cp, and for brute-force copy there is dd.
>
> Most of the time I *do* just "cheap out" with system("cp ....").
> It's easy, it works - albeit a bit ugly and "un-C".
>
> I did find that "mv" doesn't always get it right ... if a filename
> includes weirdo characters. "File ~$$$ Stuff.doc" can be translated
> as an escape sequence no matter whether you put quotes around the
> mess or not. 'C' rename() works right every time though.

How can you possibly be a C programmer and not know, already, the
reasons why for your above issue.

man 3 system:
system() executes a command specified in command by calling /bin/sh -c
command,

If you use system(), your call goes through /bin/sh, which means you
have to quote shell-metacharacters appropriately to have them ignored
by the interpretation /bin/sh will attempt to perform.

The rename() function does not go through /bin/sh, it eventually
becomes a syscall into the kernel ABI to perform the rename.

> So, if rename(), why not a standard fcopy() with a few useful
> options too ?

No one here knows the actual answer. Many have given their guesses,
and more than a few others have argued why many of the guesses may
themselves be wrong.

You'd need to ask the people responsible for deciding what got put into
C's libc, and no one on the group here was involved in any of those
decisions, so everyone is just guessing.

> If the Linux clique isn't sure I guess we'll never know for sure.

Linux simply used the existing C libraries, but had no direct hand in
deciding what was included. The C library is distributed as an
independent entity:

https://en.wikipedia.org/wiki/GNU_C_Library
https://www.gnu.org/software/libc/

Linux just makes use of that pre-existing, independent entity.

Your question here to a Linux group about why no fcopy() in libc would
be similar to asking a Tailor who is showing you some fine wool cloth
for a suit you are having made what specific feedstock the sheep who
grew the wool were fed. The tailor likely has no idea what specific
feedstock the sheep ate. Correspondingly, Linux people, who had no had
in making the decisions as to what got included in GNU libc (and
everyone in the group here falls into this category), also have no
knowledge of the real reasons why an given function was chosen for
inclusion, or why some other function was never added.

All we have are guesses.

On 05/13/2021 06:02 AM, MSB wrote:

> So, if rename(), why not a standard fcopy() with a few
> useful options too ? If the Linux clique isn't sure I guess
> we'll never know for sure. I've been informed that Ritchie
> is deceased ......

There is a rename() function because it has to access file-system
structures that are only known to the kernel.

fcopy() isn't a standard function which can be implemented in few lines
of code but in my long experience - I started in the late '70 using
punched cards on a IBM mainframe with PL/1 - never had to copy a file.

The standard libc is mostly a collection of standard functions whose
purpose is to interact with structures handled only by the kernel.
Most functions are defined in international standards as POSIX and ISO.
You can ask the committees that issue the standards.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

On 13.5.21 7.02, MSB wrote:
> On Wed, 12 May 2021 19:54:01 +0300, Tauno Voipio
> <tauno.voipio@notused.fi.invalid> wrote:
>
>> For simple copy we have cp, and for brute-force copy there is dd.
>
>
> Most of the time I *do* just "cheap out" with system("cp ....").
> It's easy, it works - albeit a bit ugly and "un-C".
>
> I did find that "mv" doesn't always get it right ... if a filename
> includes weirdo characters.

mv is *not* a copy operation, it is a shell cover for the rename()
system call.

--

-TV

On 2021-05-13, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> On 13.5.21 7.02, MSB wrote:
>> On Wed, 12 May 2021 19:54:01 +0300, Tauno Voipio
>> <tauno.voipio@notused.fi.invalid> wrote:
>>
>>> For simple copy we have cp, and for brute-force copy there is dd.
>>
>>
>> Most of the time I *do* just "cheap out" with system("cp ....").
>> It's easy, it works - albeit a bit ugly and "un-C".
>>
>> I did find that "mv" doesn't always get it right ... if a filename
>> includes weirdo characters.
>
> mv is *not* a copy operation, it is a shell cover for the rename()
> system call.

At least in old-days Unix, if the source and destination are on
different mountpoints, "mv" will copy the file to the destination
directory/file and then delete the source. Does the rename()
system call do that? The man page does not say it does.

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

On Thu, 13 May 2021 16:53:20 +0200, Giovanni <lsodgf0@home.net.it>
wrote:

>On 05/13/2021 06:02 AM, MSB wrote:
>
>> So, if rename(), why not a standard fcopy() with a few
>> useful options too ? If the Linux clique isn't sure I guess
>> we'll never know for sure. I've been informed that Ritchie
>> is deceased ......
>
>There is a rename() function because it has to access file-system
>structures that are only known to the kernel.
>
>fcopy() isn't a standard function which can be implemented in few lines
>of code but in my long experience - I started in the late '70 using
>punched cards on a IBM mainframe with PL/1 - never had to copy a file.

Eh ??? I don't find that entirely credible.

Of course space WAS at a premium back then.

Not so good when your paper tape shredded ...

Now some of the peripherials of that era did a lot of
the work by themselves. "Duplicate To" could
sometimes be handled completely off the CPU.

According to IBM, in PL/1 you would do much as
you do now in 'C' ... read & write ... in order to copy.

>The standard libc is mostly a collection of standard functions whose
>purpose is to interact with structures handled only by the kernel.
>Most functions are defined in international standards as POSIX and ISO.
>You can ask the committees that issue the standards.

Not the perfect explaination, especially given the plethora of
functions in the standard libs, but it has a high truthiness
factor. Basically they saw no need and therefore didn't
bother.

On Thu, 13 May 2021 18:40:57 +0300, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:

>On 13.5.21 7.02, MSB wrote:
>> On Wed, 12 May 2021 19:54:01 +0300, Tauno Voipio
>> <tauno.voipio@notused.fi.invalid> wrote:
>>
>>> For simple copy we have cp, and for brute-force copy there is dd.
>>
>>
>> Most of the time I *do* just "cheap out" with system("cp ....").
>> It's easy, it works - albeit a bit ugly and "un-C".
>>
>> I did find that "mv" doesn't always get it right ... if a filename
>> includes weirdo characters.
>
>mv is *not* a copy operation, it is a shell cover for the rename()
>system call.

But it does NOT always work the same. Names with any
kind of "escape" characters MAY not be handled properly.
Beware. I discovered this doing a backup app that handled
half a million files (mostly Winders files). Every time there
would be a handful of mistakes. Traced it to system("mv ...")

On 14 May 2021 02:18:40 GMT, Robert Riches <spamtrap42@jacob21819.net>
wrote:

>On 2021-05-13, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
>> On 13.5.21 7.02, MSB wrote:
>>> On Wed, 12 May 2021 19:54:01 +0300, Tauno Voipio
>>> <tauno.voipio@notused.fi.invalid> wrote:
>>>
>>>> For simple copy we have cp, and for brute-force copy there is dd.
>>>
>>>
>>> Most of the time I *do* just "cheap out" with system("cp ....").
>>> It's easy, it works - albeit a bit ugly and "un-C".
>>>
>>> I did find that "mv" doesn't always get it right ... if a filename
>>> includes weirdo characters.
>>
>> mv is *not* a copy operation, it is a shell cover for the rename()
>> system call.
>
>At least in old-days Unix, if the source and destination are on
>different mountpoints, "mv" will copy the file to the destination
>directory/file and then delete the source. Does the rename()
>system call do that? The man page does not say it does.

It does for sure if the file being renamed is on the SAME
mountpoint. I'll have to check if it behaves the same if
we're talking two mountpoints. Interesting question.
I usually try to rename (or gzip for that matter) on ONE
mountpoint for speed and simplicity. If there's a problem
I've unconsciously gone around it for decades.

And there's one of the BIG problems of software verification,
the condition a given programmer/user has NEVER managed
to evoke because it's just not in their thought paradigm. I *do*
always try to throw some BS at critical functions, just to make
sure, but I guarentee there are combinations of conditions
I miss.

MSB <Bit15_.us> wrote:
> On Thu, 13 May 2021 18:40:57 +0300, Tauno Voipio
> <tauno.voipio@notused.fi.invalid> wrote:
>
>>On 13.5.21 7.02, MSB wrote:
>>> On Wed, 12 May 2021 19:54:01 +0300, Tauno Voipio
>>> <tauno.voipio@notused.fi.invalid> wrote:
>>>
>>>> For simple copy we have cp, and for brute-force copy there is dd.
>>>
>>>
>>> Most of the time I *do* just "cheap out" with system("cp ....").
>>> It's easy, it works - albeit a bit ugly and "un-C".
>>>
>>> I did find that "mv" doesn't always get it right ... if a filename
>>> includes weirdo characters.
>>
>>mv is *not* a copy operation, it is a shell cover for the rename()
>>system call.
>
> But it does NOT always work the same. Names with any
> kind of "escape" characters MAY not be handled properly.

That is not mv's fault. That is the fault of the programmer who did
not properly escape shell special characters when using system() to
call 'mv'. The system() library call uses /bin/sh, so all the
characters that are special to /bin/sh have to first be escaped so
/bin/sh will not modify them.

On Thu, 13 May 2021 12:32:53 -0000 (UTC), Rich <rich@example.invalid>
wrote:

>MSB <Bit15_.us> wrote:
>> On Wed, 12 May 2021 13:20:47 -0000 (UTC), Rich <rich@example.invalid>
>> wrote:
>>
>>>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.
>>
>> Sorry, but I almost exclusively use Linux and it's
>> written amost entirely in 'C' .... so this ISN'T a
>> stupid place to ask the question.
>
>Other than C's libc, and the group of functions provided therein, were
>more or less standardized long before Linux existed. Linux may be
>mostly written in C, but that does not mean the authors of Linux also
>wrote the C compiler or the C library functions. There may be some
>crossover between the two, but gcc (the C compiler from GNU) and
>gnulibc (the C libraries, also from GNU) both existed before Linux.

UNIX came first, then 'C' made it better. Linus, fortunately,
didn't re-invent the 'C' wheel. Hey, just for fun, he MIGHT
have decided to write it all in BASICA or Lisp or something :-)

Hmm ... been looking at "alternatives" lately. Today I looked
at "Gambas". It's CLOSE to Visual BASIC. The environment
reminds me of Delphi/Lazarus but the code is a bit more
simple. Had a few weird issues, I'll see what the problems
are tomorrow or so. DOES produce a compiled product
however, which is better than Python (and Cython/Nutika
won't always save you there).

Long LONG ago I wrote a data-entry app for a Psion
Organizer. BASIC. It was essentially a long GOTO
ladder which let you go down or back at a keystroke.
Dunno if Gambas still does GOTO. It CAN be useful
and a big time/space saver if employed properly.

But that's another thread.

>> My next question is why you think I'm "trolling". It
>> was a perfectly legit historical question. I thought
>> there'd be ONE clear answer ... but no ......
>
>Your initial post did not look like a troll. But your subsequent goal
>post shifting, revisionist history, feigning confusion, and
>argumentative posts look very trollish.

Usenet threads "evolve" ... that's how it works. Start with
one subject and then it branches out. EVENTUALLY you
get a bunch of new threads that specialize on those
branches. Then THEY evolve ....

"Stream of consciousness" ?

On Wed, 12 May 2021 09:14:24 +0100, Richard Kettlewell
<invalid@invalid.invalid> wrote:

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

Nope. Was talking about GCC actually (or Clang, almost the
same thing these days).

NO fcopy() in GCC.

Yes, it's easy to write - but after DECADES you'd think there
would be a "standard" function with a few useful options so
everybody would be on the same page, so to speak. Mostly,
such "standardization" is a GOOD thing.

Python has open statements with "r" OR "rb" ... yes, Python
has issues with binary. 'C' *can* handle things just a tad
differently depending on whether you use open/read/write
or fopen/fread/fwrite ... mostly a matter of how fwrite()
can try to "fix" line-endings, assuming you're doing text
files and want newlines at the end and/or "escape"
sequences interpreted. A fcopy() with "r" or "rb", "w" or
"wb" options, doesn't seem ridiculous as a "standard".

I've heard various reasons here why fcopy() was never
included in a standard libary. Some sound legit, others
not so much. There are just SO many quasi-useless
things in todays libraries ... I see a "hole" that's been
there pretty much from the beginning.

On Fri, 14 May 2021 04:14:37 -0000 (UTC), Rich <rich@example.invalid>
wrote:

>MSB <Bit15_.us> wrote:
>> On Thu, 13 May 2021 18:40:57 +0300, Tauno Voipio
>> <tauno.voipio@notused.fi.invalid> wrote:
>>
>>>On 13.5.21 7.02, MSB wrote:
>>>> On Wed, 12 May 2021 19:54:01 +0300, Tauno Voipio
>>>> <tauno.voipio@notused.fi.invalid> wrote:
>>>>
>>>>> For simple copy we have cp, and for brute-force copy there is dd.
>>>>
>>>>
>>>> Most of the time I *do* just "cheap out" with system("cp ....").
>>>> It's easy, it works - albeit a bit ugly and "un-C".
>>>>
>>>> I did find that "mv" doesn't always get it right ... if a filename
>>>> includes weirdo characters.
>>>
>>>mv is *not* a copy operation, it is a shell cover for the rename()
>>>system call.
>>
>> But it does NOT always work the same. Names with any
>> kind of "escape" characters MAY not be handled properly.
>
>That is not mv's fault. That is the fault of the programmer who did
>not properly escape shell special characters when using system() to
>call 'mv'. The system() library call uses /bin/sh, so all the
>characters that are special to /bin/sh have to first be escaped so
>/bin/sh will not modify them.

Sorry, but I collect filenames and then DO stuff
with them - and do NOT want to have to out-think
"mv" for every possible instance, making my code
five times larger and more complex.

So, now, it's rename() instead of system("mv ...)
forever and always.

I ran into this problem in a backup app that was handling
over half a million (mostly Winders) files. There would
always be a handful of problem cases - which I traced
to system("mv ..."). So, 200 lines of code looking for
everything/anything that might possibly be seen by the
system as an "escape" sequence, today - or rename() ?