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
10 matches
Mail list logo
