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 -
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 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 befor
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 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 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 deplo
On 27/02/19 14:20, Derek Dongray wrote:
> When trying to use mv to rename a file on an external drive using coreutils
> 8.30-2 on a debian system (Linux version 4.19.0-3-amd64), the rename fails
> with the error message:
>
> mv: cannot move 'file1' to a subdirectory of itself 'file2'
>
> Down
On 17/03/16 17:38, Paul Eggert wrote:
> On 03/16/2016 08:51 PM, Assaf Gordon wrote:
>> I suspect it has something to do with this commit:
>>commit037e3b9847feb46cf6b58d99ce960d3987faaf52
>
> You're right, and thanks for that detailed bug report. I installed the
> attached patch, which fix
On 12/02/16 01:47, Jaroslav Skarvada wrote:
> Hi,
>
> please revert this ugly change, it's confusing and against GNU coding
> standards [1]:
>
>> Likewise, please don’t make the behavior of a command-line program depend
>> on the type of output device it gets as standard output or standard input
On 18/07/15 19:38, Leslie Rhorer wrote:
> Package: coreutils
> Version: 8.23-4
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> CRC checks on large files often return variable values. I have tried several
> different CRC check utilities, md5sum, md6sum, sha56
On 08/06/2013 08:32 PM, Bob Proulx wrote:
> Volker Klasen opened a bug in the Debian bug tracker concerning a
> change in behavior in cut. I have CC'd the bug on this message. I
> have manually set an appropriate Reply-To header.
>
> http://bugs.debian.org/718898
>
> There has been a lot of i
I upgraded from 1.6.4 to 1.6.7 and...
pcscd logs end with: readerfactory.c:1301:RFWaitForReaderInit() Waiting init
for reader: CASTLES EZ710PU 00 01
Clients are blocked like: futex(0x2c6260, FUTEX_WAIT_PRIVATE, 2, NULL...
Note this device presents 2 readers.
00 00 = smartcard, 00 01 = rfid
Some
12 matches
Mail list logo
