As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the >modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B". Even brain-dead systems don't do that.
In article <khv4chFlvvnU1@mid.individual.net>,
Frank Winkler <usenet@f.winkler-ka.de> wrote:
...
As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the
modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B". Even brain-dead systems don't do that.
Yes, that's a long standing misfeature. It is one of those: They picked
the wrong default in the beginning and every Unix "copy" program, from cp
to rsync, et al, has had to do the wrong thing by default ever since. You need a command line option (-p or -a or something like that) in order to
get the sensible behavior.
Note that "mcp" does the right thing by default. That's the only
exception to the above rule that I can think of.
On 21.07.23 14:00, Chris Elvidge wrote:
"cp A B" creates a new file 'B' so B has new modification time (unless
overidden).
Creation, not modification.
mcp : command not found - slackware and lmde5
I also don't know that one, neither on Solaris nor macOS nor Linux nor >whatever ;) ...
In article <khvaveFlvvnU2@mid.individual.net>,
Frank Winkler <usenet@f.winkler-ka.de> wrote:
On 21.07.23 14:00, Chris Elvidge wrote:
>"cp A B" creates a new file 'B' so B has new modification time (unless
>overidden).
Creation, not modification.
Yes. Everybody knows that. The point is: It is a historical misfeature.
>mcp : command not found - slackware and lmde5
I also don't know that one, neither on Solaris nor macOS nor Linux nor
whatever ;) ...
Have neither you nor Chris heard of these wonderful pieces of software
called "package managers"? They're really cool, and you should look into them. They are so cool - you just run them and they install new software
on your system that you didn't have before. What's even better is that
these package manager thingies *are* usually installed by default on your Linux system(s), you don't even have to explicitly get and install them.
They just work. It is soooooooo kewl!
On 21.07.23 14:24, Kenny McCormack wrote:
Have neither you nor Chris heard of these wonderful pieces of software
called "package managers"? They're really cool, and you should look into
Of course I have. But even with a package manager, I only install things
that I know of. And just as an example, MacPorts also doesn't seem to
know it:
On 21.07.23 14:24, Kenny McCormack wrote:
Have neither you nor Chris heard of these wonderful pieces of software
called "package managers"? They're really cool, and you should look into
Of course I have. But even with a package manager, I only install things
that I know of. And just as an example, MacPorts also doesn't seem to
know it:
There's also this really cool thing - called "google". You can find out
all kinds of stuff using it. It's really amazing.
On 21/07/2023 11:54, Kenny McCormack wrote:
In article <khv4chFlvvnU1@mid.individual.net>,
Frank Winkler <usenet@f.winkler-ka.de> wrote:
...
As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the
modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B". Even brain-dead systems don't do that.
"cp A B" creates a new file 'B' so B has new modification time (unless overidden).
"mv A B" should really be advertised as "rename A B" (unless A and B are
on different filesystems).
Yes, that's a long standing misfeature. It is one of those: They pickedmcp : command not found - slackware and lmde5
the wrong default in the beginning and every Unix "copy" program, from cp
to rsync, et al, has had to do the wrong thing by default ever since. You >> need a command line option (-p or -a or something like that) in order to
get the sensible behavior.
Note that "mcp" does the right thing by default. That's the only
exception to the above rule that I can think of.
mcp : command not found - slackware and lmde5
On 21/07/2023 11:54, Kenny McCormack wrote:
In article <khv4chFlvvnU1@mid.individual.net>,
Frank Winkler <usenet@f.winkler-ka.de> wrote:
...
As many other people already said, that assumption is wrong. And to go
one step further, IMO it rather sucks that UNIX "cp" _does_ update the
modification date unless using "-p". I never understood why it behaves
this way as the content is untouched and why B should have a different
time stamp than A after "cp A B". Even brain-dead systems don't do that.
"cp A B" creates a new file 'B' so B has new modification time (unless overidden).
"mv A B" should really be advertised as "rename A B" (unless A and B are
on different filesystems).
On 2023-07-21, Chris Elvidge <chris@mshome.net> wrote:
mcp : command not found - slackware and lmde5
mcp seems to be something that was written by one
Vladimir Lanin <lanin@csd2.nyu.***>
in the year 1989 (or earlier).
mcp is one of the links (or symlinks) to a single executable.
It has four names: mmv, mcp, mad and mln, which implicitly specify a
default action of -x, -c, -a or -l.
It looks nice; why isn't it better known.
On 7/22/2023 2:25 AM, Kaz Kylheku wrote:
On 2023-07-21, Chris Elvidge <chris@mshome.net> wrote:
mcp : command not found - slackware and lmde5
mcp seems to be something that was written by one
Vladimir Lanin <lanin@csd2.nyu.***>
in the year 1989 (or earlier).
mcp is one of the links (or symlinks) to a single executable.
It has four names: mmv, mcp, mad and mln, which implicitly specify a
default action of -x, -c, -a or -l.
It looks nice; why isn't it better known.
IIRC, in System V, cp, mv, and ln were all links to a single executable.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 43:28:53 |
| Calls: | 6,910 |
| Files: | 12,376 |
| Messages: | 5,429,283 |