On 01/02/2024 00:36, Paul Eggert wrote:
On 1/31/24 06:06, Pádraig Brady wrote:
To my mind the most protective option takes precedence.
That's not how POSIX works with mv -i and mv -f. The last flag wins. I
assume this is so that people can have aliases or shell scripts that
make -i the
On 1/31/24 06:06, Pádraig Brady wrote:
To my mind the most protective option takes precedence.
That's not how POSIX works with mv -i and mv -f. The last flag wins. I
assume this is so that people can have aliases or shell scripts that
make -i the default, but you can override by specifying
On 30/01/2024 18:31, Paul Eggert wrote:
On 2024-01-30 03:18, Pádraig Brady wrote:
So we now have the proposed change as:
- revert -n to old silent success behavior
- document -n as deprecated
- Leave --update=none as is (will be synonymous with -n)
- Provide --update=none-fail
On 2024-01-30 03:18, Pádraig Brady wrote:
So we now have the proposed change as:
- revert -n to old silent success behavior
- document -n as deprecated
- Leave --update=none as is (will be synonymous with -n)
- Provide --update=none-fail to diagnose and exit failure
Thanks, that's
On 29/01/2024 21:44, Paul Eggert wrote:
On 1/29/24 08:11, Pádraig Brady wrote:
Right, that's why I'm still leaning towards my proposal in the last mail.
Well, I won't insist on doing nothing; however, the proposal needs
ironing out and now's a good time to do it before installing changes.
On 1/29/24 08:11, Pádraig Brady wrote:
Right, that's why I'm still leaning towards my proposal in the last mail.
Well, I won't insist on doing nothing; however, the proposal needs
ironing out and now's a good time to do it before installing changes.
- revert to previous exit success
On Mon, Jan 29, 2024 at 04:11:05PM +, Pádraig Brady wrote:
You've introduced a silent incompatibility and I'm trying to find some
way to make that clear. If upstream would provide a better solution I
would certainly use it. I have despaired of there being such since your
attitude thus far
On 29/01/2024 14:01, Michael Stone wrote:
On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote:
I'm not sure reverting would be best. It would introduce more
confusion, and would make coreutils incompatible with FreeBSD again.
Reverting makes more sense than the current situation. I do
On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote:
I'm not sure reverting would be best. It would introduce more
confusion, and would make coreutils incompatible with FreeBSD again.
Reverting makes more sense than the current situation. I do not
understand why you seem to value
On 2024-01-28 05:22, Pádraig Brady wrote:
At this stage it seems best for us go back to the original Linux
behiavor (use case 3),
and to silently deprecate -n in docs to document the portability issues
with it.
I'm not sure reverting would be best. It would introduce more confusion,
and
On 17/12/2023 14:46, Pádraig Brady wrote:
On 16/12/2023 21:46, Bernhard Voelker wrote:
On 12/15/23 21:13, Michael Stone wrote:
On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:
Stlll, Pádraig gave a reasonable summary of why the change was made,
To clarify my summary a little,
Paul Eggert wrote on Fri, Dec 15, 2023 at 11:21:06AM -0800:
> The cat is to some extent out of the bag. Unless one insists on (FreeBSD |
> coreutils 9.2-9.4), or insist on coreutils 7.1-9.1, one should not rely on
> cp -n failing or silently succeeding when the destination already exists.
> This
On Sun, Dec 17, 2023 at 12:34:11AM -0800, Paul Eggert wrote:
On 2023-12-16 13:46, Bernhard Voelker wrote:
Whether the implementation is race-prone or not is an internal thing.
I wasn't referring to the internal implementation. I was referring to
cp users. With the newer Coreutils (FreeBSD)
On 16/12/2023 21:46, Bernhard Voelker wrote:
On 12/15/23 21:13, Michael Stone wrote:
On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:
Stlll, Pádraig gave a reasonable summary of why the change was made,
To clarify my summary a little, there I said that -n now _immediately_ fails.
On 2023-12-16 13:46, Bernhard Voelker wrote:
Whether the implementation is race-prone or not is an internal thing.
I wasn't referring to the internal implementation. I was referring to cp
users. With the newer Coreutils (FreeBSD) behavior, you can reliably
write a script to do something if
On 12/15/23 21:13, Michael Stone wrote:
On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:
Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less
On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:
Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less race-prone.) It seemed
like a good idea at
On 2023-12-15 10:49, Michael Stone wrote:
There's no compelling reason to force this change
Well, certainly nobody compelled us at gunpoint
Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that
On Fri, Dec 15, 2023 at 06:33:00PM +, Pádraig Brady wrote:
Advantages of leaving as is:
We get consistency of "noclobber" behavior across systems / shells.
You don't, unless you ignore the coreutils/linux installed base
entirely. Essentially the current situation is that -n shouldn't be
On 15/12/2023 15:56, Michael Stone wrote:
I tend to think this was a serious mistake: it breaks the behavior of
existing scripts with no deprecation period. A stated advantage is
better compatibility with freebsd, but I don't understand why that is
more desirable than compatibility with all
I tend to think this was a serious mistake: it breaks the behavior of
existing scripts with no deprecation period. A stated advantage is
better compatibility with freebsd, but I don't understand why that is
more desirable than compatibility with all deployed gnu/linux systems? I
also don't
Take 2 attached.
cheers,
Pádraig
From 849aa5658c0fbf1e8d2baec2fc3b01b2ddb23c50 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sat, 1 Apr 2023 16:27:52 +0100
Subject: [PATCH] cp,mv: add --update=none to always skip existing files
Add --update=none which is equivalent to
On 01/04/2023 23:44, Paul Eggert wrote:
On 2023-04-01 08:44, Pádraig Brady wrote:
OK first stab at --update=none support is attached.
Thanks, some comments:
+ /* Always Overwrite. */
+ UPDATE_OVERWRITE,
Might be better to call this UPDATE_ALL as it doesn't overwrite if you
use cp -l
On 2023-04-01 08:44, Pádraig Brady wrote:
OK first stab at --update=none support is attached.
Thanks, some comments:
+ /* Always Overwrite. */
+ UPDATE_OVERWRITE,
Might be better to call this UPDATE_ALL as it doesn't overwrite if you
use cp -l or -s or (in some cases)
Maybe simpler:
-m --missing
Only copy non existing files.
On Sat, 1 Apr 2023 at 17:44, Pádraig Brady wrote:
> On 01/04/2023 00:29, Paul Eggert wrote:
> > On 2023-03-31 14:32, Pádraig Brady wrote:
> >
> >> Perhaps we should support:
> >> --no-clobber[={skip, fail (default)}]
> >>
> >> so
On 01/04/2023 00:29, Paul Eggert wrote:
On 2023-03-31 14:32, Pádraig Brady wrote:
Perhaps we should support:
--no-clobber[={skip, fail (default)}]
so then users can at least easily change -n to --no-clobber=skip
to get the old behavior?
An alternative would be to augment the --update
On 01/04/2023 15:46, Alberto Salvia Novella wrote:
Also there's now a bigger problem: that you cannot tell when the copy
failed because the file exists, or because any other reason.
People will just use:
cp --no-clover $in $out || true
But if it fails for any other reason, cross your fingers.
Also there's now a bigger problem: that you cannot tell when the copy
failed because the file exists, or because any other reason.
People will just use:
cp --no-clover $in $out || true
But if it fails for any other reason, cross your fingers.
Hence now the option, in practice, is useless.
Or use:
cp --no-clover $in $out || true
But again, surprising behavior. Just a new special case to memorize.
On Sat, 1 Apr 2023 at 03:36, Alberto Salvia Novella
wrote:
> I get the impression that right now --no-clover is optimized for the less
> common scenarios, while making it less useful
I get the impression that right now --no-clover is optimized for the less
common scenarios, while making it less useful for the common ones.
Also --update isn't a substitute of --no-clover. As --no-clover is for
copying when the file is missing, not when it isn't updated.
For example imagine
In principle I have no strong opinion on what the behaviour should be.
But if one strictly follows the POSIX wording:
>The following exit values shall be returned:
> 0
>All input files were [copied/moved] successfully.
>>0
>An error occurred.
The change seems to make
On 2023-03-31 14:32, Pádraig Brady wrote:
Perhaps we should support:
--no-clobber[={skip, fail (default)}]
so then users can at least easily change -n to --no-clobber=skip
to get the old behavior?
An alternative would be to augment the --update option to support:
--update[={none, older
On 31/03/2023 22:15, Paul Eggert wrote:
On 2023-03-31 13:37, Sven Joachim wrote:
On 2023-03-31 13:01 -0700, Paul Eggert wrote:
part of the idea was to let shell programmers easily test whether
cp successfully copied the data.
By making them stop using the '-n' option, since they cannot rely
On 2023-03-31 13:37, Sven Joachim wrote:
On 2023-03-31 13:01 -0700, Paul Eggert wrote:
part of the idea was to let shell programmers easily test whether
cp successfully copied the data.
By making them stop using the '-n' option, since they cannot rely on the
exit code anyway?
Portable code
https://youtu.be/o_kh1_gOkwk
On Fri, 31 Mar 2023 at 22:01, Paul Eggert wrote:
> On 2023-03-31 10:01, Alberto Salvia Novella wrote:
> > Is this on purpose?
>
> Yes, part of the idea was to let shell programmers easily test whether
> cp successfully copied the data. Having cp -i conform to POSIX
On 2023-03-31 13:01 -0700, Paul Eggert wrote:
> On 2023-03-31 10:01, Alberto Salvia Novella wrote:
>> Is this on purpose?
>
> Yes, part of the idea was to let shell programmers easily test whether
> cp successfully copied the data.
By making them stop using the '-n' option, since they cannot
On 2023-03-31 10:01, Alberto Salvia Novella wrote:
Is this on purpose?
Yes, part of the idea was to let shell programmers easily test whether
cp successfully copied the data. Having cp -i conform to POSIX was a
lesser consideration, though it's a bit nicer if -n and -i are somewhat
Alberto Salvia Novella writes:
> In the past if you did:
> cp --no-clobber $in $out
>
> And "out" existed, "cp" exited with 0. But now, with coreutils 9.2, it
> exists with 1.
>
> Is this on purpose?
>
> (When replying include my email in the field "to", as I'm not subscribed to
> this list)
In the past if you did:
cp --no-clobber $in $out
And "out" existed, "cp" exited with 0. But now, with coreutils 9.2, it
exists with 1.
Is this on purpose?
(When replying include my email in the field "to", as I'm not subscribed to
this list)
39 matches
Mail list logo
