On 3/20/24 15:53, Bernhard Voelker wrote:
$ echo 1 > a
$ mkdir d
$ echo 2 > d/a
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
$ cat a
2
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
On 3/20/24 14:43, Bernhard Voelker wrote:
> On 3/17/24 07:10, Paul Eggert wrote:
> Now, extending "exchange" to more arguments is confusing and the
> use is not intuitive:
>mv -v --exchange a b c d
It's also pointless. An atomic exchange on more than 2 files ISN'T ATOMIC.
That's why I didn't
On 13/03/2024 10:19, Matheus Afonso Martins Moreira wrote:
About a year ago, I posted an env feature request on this list:
the ability to set the value of argv[0].
https://lists.gnu.org/archive/html/coreutils/2023-03/msg2.html
I also sent a patch:
On 3/20/24 21:56, Paul Eggert wrote:
On 3/20/24 12:43, Bernhard Voelker wrote:
This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more
On 3/17/24 04:32, Pádraig Brady wrote:
I think the --no-copy situation is brittle, as scripts not using it now
would be atomic, but then if we ever supported cross fs swaps
it may become non atomic. I'd at least doc with a line in the --exchange
description in usage() to say something like:
On 2024-03-19 16:53, Pádraig Brady wrote:
> but would appreciate a quick review of the fts_level usage in the second
> patch.
>
> thanks,
> Pádraig
In utilities that perform tree walks, there may be reasons why
not following links is a useful option, but it can't be relied on
for security.
On 3/20/24 12:43, Bernhard Voelker wrote:
This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.
Yes, that's mv's original sin,
On 3/17/24 07:10, Paul Eggert wrote:
Although removing that "mv --swap" implementation was a win, I don't
think we can simply delegate this to util-linux's exch command.
I still have some headache adding this.
This stems from the fact that although mv(1) is a userland frontend
for
On 16/12/2011 16:29, Jan Engelhardt wrote:
Hi,
chown(1) has a -h option by which it affects symlinks directly rather
than the pointed-to file. The bonus side effect is that the
pointed-to files don't get changed in any way, which is kinda welcome
if you attempt to "fix" permissions/ownership in
On 28/03/2012 21:28, Paul Eggert wrote:
On 03/28/2012 01:13 PM, Jim Meyering wrote:
$ ./chmod u+w f
./chmod: changing permissions of 'f': Operation not supported
Yeouch. I undid the change for now.
Hmm, why did "make check" work for me?
I'll have to investigate later, alas.
Patch
On Tue, 19 Mar 2024, Zachary Santer wrote:
On Tue, Mar 19, 2024 at 1:24 AM Kaz Kylheku wrote:
But what tee does is set up _IONBF on its output streams,
including stdout.
So it doesn't buffer at all. Awesome. Nevermind.
Yay! :D
And since tee uses fwrite to copy whatever input is
11 matches
Mail list logo
