On 2024-04-06 03:09, Pádraig Brady wrote:
I'll apply this.
Heh, I beat you to it by looking for similar errors elsewhere and
applying the attached patches to fix the issues I found. None of them
look like serious bugs.
BTW we should improve sort buffer handling in general
Oh yes.
PS.
On Apr 05 2024, "Branden R. Williams" via GNU coreutils Bug Reports wrote:
> That’s not an accurate representation of what the command actually does. The
> argument after -k MUST be the kill signal code, without the code the command
> fails. The manpage and help document agree with what you are
That’s not an accurate representation of what the command actually does. The
argument after -k MUST be the kill signal code, without the code the command
fails. The manpage and help document agree with what you are saying but the
execution of the program fails.
That functionality is not
Hi,
I have found a performance issue with the sort command when used on
pseudo files with zero size. For instance, sorting `/proc/kallsyms`, as
demonstrated below, takes significantly longer than executing with
`cat`, generating numerous temporary files. I confirmed this issue on
v8.32 as well
On 06/04/2024 03:52, Takashi Kusumi wrote:
Hi,
I have found a performance issue with the sort command when used on
pseudo files with zero size. For instance, sorting `/proc/kallsyms`, as
demonstrated below, takes significantly longer than executing with
`cat`, generating numerous temporary
Branden,
Then how come timeout -k 10s 20s ping 8.8.8.8 works?
10s is DEFINITELY NOT an integer. 20s in the timeout value.
I still think your reasoning is suspect.
On 06/04/2024 at 13:43, Branden R. Williams wrote:
I understand this, but the manpage and the help file do not explain the
Working from the code published here:
https://github.com/coreutils/coreutils/blob/master/src/timeout.c
If you look at the code, you can see the kill_after variable set on line 486 if
the switch is there. In the cleanup() function on line 202, it looks for that
variable to be st on line 212,
I understand this, but the manpage and the help file do not explain the
functionally this way. The manpage suggests that the following should work:
$ timeout -k 10s sleep 10
It does not because the first argument after -k MUST be the an integer value of
the signal you want to send, not the
tag 70219 notabug
close 70219
stop
On 06/04/2024 16:50, Branden R. Williams via GNU coreutils Bug Reports wrote:
-k, --kill-after=DURATION
also send a KILL signal if COMMAND is still running
this long after the initial signal was sent
If you read the
