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 <es204904...@gmail.com>
wrote:
> 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 that I have a config template, and a script copies the
> template only if it is missing using --no-clover.
>
> If I did the same with --update it could happen the following: the package
> that provides the template updates, then --update will override the config
> even if it exists, just because the source file is now newer. No good.
>
> So right now the only option that I have is to avoid both --no-clover and
> --update all together, and to test for the file existence separately. So
> totally useless.
>
> On Sat, 1 Apr 2023 at 01:29, Paul Eggert <egg...@cs.ucla.edu> 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 option to support:
>> > --update[={none, older (default)}]
>> > where --update=none would be the equivalent of the old -n behavior.
>>
>> The latter sounds a bit better but I suppose either would work. We could
>> generalize it a bit further, e.g.:
>>
>> --skip-diagnose[={yes,no}]
>> Whether to diagnose a copying action being skipped.
>> --skip-fail[={yes,no}]
>> Whether exit status should be 1 when skipping a copying action.
>>
>> Presumably similar options would apply to ln and mv.
>>
>> All these extra options might be overkill, though.
>>
>>
>> > Perhaps we should also diagnose files skipped in the -n fail case,
>> > to make it easier for users to see what the issue is.
>>
>> FreeBSD cp -n doesn't diagnose, and GNU cp -n has never diagnosed, so
>> it's probably better to leave sleeping dogs lie.
>>
>
