On Mon, Mar 04, 2024 at 04:24:27PM -0800, Paul Eggert wrote:
> On 3/4/24 15:37, Petr Malat wrote:
> > Why do you expect this?
>
> I expect it because mv has always treated destination directories that way.
> This has been true since the 1970s. We should not change this basic mode of
> operation.
On Mon, Mar 04, 2024 at 08:35:03PM +, P??draig Brady wrote:
> On 04/03/2024 15:47, P??draig Brady wrote:
> > On 04/03/2024 00:44, Paul Eggert wrote:
> > > Although I like the idea of exposing file swaps to the user, the first
> > > cut of 'mv -x' has significant problems.
> > >
> > > I expect
Hi Paul,
On Sun, Mar 03, 2024 at 04:44:52PM -0800, Paul Eggert wrote:
> Although I like the idea of exposing file swaps to the user, the first cut
> of 'mv -x' has significant problems.
>
> I expect 'mv -x A B' to act like 'mv A B' except the destination must exist
> and is renamed back to A.
On 3/4/24 18:43, Dominique Martinet wrote:
> Adding Rob to the loop because this impacts compatibility with
> toybox/maybe busybox implementations
> (Quoting in full for convenience, there's a few more mails in
> https://lists.nongnu.org/archive/html/bug-coreutils/2024-03/msg2.html
> but we
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
(Quoting in full for convenience, there's a few more mails in
https://lists.nongnu.org/archive/html/bug-coreutils/2024-03/msg2.html
but we seem to be missing Petr's reply)
Pádraig Brady wrote
Paul Eggert wrote on Mon, Mar 04, 2024 at 08:10:35PM -0800:
> so there's little prior art there, and there's still plenty of time to fix
> its problems before exposing it to the world.
Yes, I just meant that everyone should agree, or there's little point in
implementing these for toybox/busybox,
On 3/4/24 12:35, Pádraig Brady wrote:
Another point worth mentioning before changing this,
is that changing would make the --swap operation non symmetric.
I.e. `mv -x a d` would be different to `mv -x d a` where d in a directory.
Yes, of course. It's just like mv without the -x. After you've
On 3/4/24 16:43, Dominique Martinet wrote:
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
Busybox does not use RENAME_EXCHANGE, so this isn't a Busybox issue.
Toybox mv added -x to its development version yesterday:
On 3/4/24 15:37, Petr Malat wrote:
Why do you expect this?
I expect it because mv has always treated destination directories that
way. This has been true since the 1970s. We should not change this basic
mode of operation.
To fix this, 'mv -x' should respect the usual mv behavior with
On 3/4/24 15:16, Petr Malat wrote:
I prefer KISS principle and allowing
swapping just 2 paths.
In that case, the option should be added to the 'rename' command, not to
'mv'.
It is not KISS to add an option to 'mv' that makes it act completely
differently, such that most of mv's other
On 04/03/2024 15:47, Pádraig Brady wrote:
On 04/03/2024 00:44, Paul Eggert wrote:
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to
On 04/03/2024 15:44, Daniel Hofstetter wrote:
Hi,
When specifying an invalid length value followed by a valid length
value I get the following error:
$ printf "hello" | cksum --algo=blake2b --length=12 --length=8
cksum: invalid length: ‘12’
cksum: length is not a multiple of 8
However, if the
On 04/03/2024 00:44, Paul Eggert wrote:
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to A. However, this is not true for 'mv -x A
B'
Hi,
When specifying an invalid length value followed by a valid length
value I get the following error:
$ printf "hello" | cksum --algo=blake2b --length=12 --length=8
cksum: invalid length: ‘12’
cksum: length is not a multiple of 8
However, if the invalid length value is a multiple of 8 and
On 3/4/24 03:10, Paul Eggert wrote:
Try running 'strace -o tr cp data.dat original' and then look at the
file 'tr' (which could be quite large). Look for the syscalls near the
start, and near the end, of the bulk copy.
Quite possibly it's a bug in your Linux drivers or your firmware or
Le ven. 1 mars 2024 à 20:30, Pádraig Brady a écrit :
> On 01/03/2024 15:33, lacsaP Patatetom wrote:
> > hi,
> >
> > I did a few tests with tr and I'm surprised by the results...
> >
> > $ echo éèçà
> > éèçà
> >
> > these characters are encoded in utf-8 on 2 bytes :
> >
> > $ echo éèçà | xxd
> >
Try running 'strace -o tr cp data.dat original' and then look at the
file 'tr' (which could be quite large). Look for the syscalls near the
start, and near the end, of the bulk copy.
Quite possibly it's a bug in your Linux drivers or your firmware or
hardware. For example, if you're using
17 matches
Mail list logo
