On 12/08/2020 18:44, Pádraig Brady wrote:
> On 12/08/2020 16:56, Jonny Grant wrote:
>> https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation
>>
>> I'd like to propose a clarification to this line:
>> "This is neede
https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation
I'd like to propose a clarification to this line:
"This is needed to support timing out commands not started directly from an
interactive shell, in two situations."
Proposal :-
"This is needed to
On 28/07/2020 23:41, Bernhard Voelker wrote:
> On 2020-07-28 23:53, Pádraig Brady wrote:
>> +1 thanks
>
> Thanks, pushed.
>
Great!
On 20/07/2020 21:04, Bernhard Voelker wrote:
> On 2020-07-05 12:53, Jonny Grant wrote:
>> Your patch looks great.
>
> Thanks, pushed (with the minor tweak mentioned below) at:
> https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=49bd08aea
>
>> Is it worth clar
On 15/06/2020 21:57, Bernhard Voelker wrote:
> Hi Jonny,
>
> On 2020-06-07 18:04, Jonny Grant wrote:
>> Hi Berny
>>
>> Sorry I was meaning to give an example of a shell command to send KILL, but
>> maybe it's not necessary.
>>
>> BTW, I s
On 05/07/2020 00:25, Bernhard Voelker wrote:
> On 2020-07-04 00:57, Jonny Grant wrote:
>> May I ask if that exit status 137 could be clarified as 128+9, where 9 is
>> the KILL signal number in this example please. I've pasted a patch below.
>
> Thanks for the patch - t
Hello
Just looking at this man page. I appreciate not the latest version. GNU
coreutils 8.32
https://man7.org/linux/man-pages/man1/timeout.1.html
Could it be clarified that a timeout DURATION of 0 also specifically inhibits
the -k, --kill-after=DURATION ?
it's implied as "this long
to this
specified duration, cumulatively from when the command is invoked."? I can make
another patch if this would be fine, and my understanding is correct.
>From b029a83e4bb6f0d51a8f9eef90b5d46905f7ffc2 Mon Sep 17 00:00:00 2001
From: Jonny Grant
Date: Fri, 3 Jul 2020 23:51:15 +0100
Subject: [
On 07/06/2020 13:39, Bernhard Voelker wrote:
On 2020-06-06 23:49, Jonny Grant wrote:
Great patch.
thanks, Padraig meanwhile further improved it.
How about writing signal 9 by the name, ie $ kill -s KILL
likewise $ kill -s TERM
Where do you mean?
Have a nice day,
Berny
Hi Berny
On 06/06/2020 00:37, Bernhard Voelker wrote:
On 2020-06-01 10:01, Jonny Grant wrote:
My mistake missing that. But could the 137 be listed explicitly?
ie.
"It may be necessary to use the KILL (9) signal, since this signal cannot be
caught, in which case the exit status is
137 (
On 01/06/2020 07:53, Andreas Schwab wrote:
On Mai 31 2020, Jonny Grant wrote:
Could the 124 and 137 be documented on the man page?
What's wrong with the last paragraph in the DESCRIPTION section?
Andreas.
My mistake missing that. But could the 137 be listed explicitly?
ie.
"I
Hello
I'm using timeout with another program that doesn't have a timeout mechanism.
Saw surprisingly timeout often returns 124
I was a bit surprised the return code as a signal was not 143 (128+ 15) for
SIGTERM. I must be missing something.
This article says 124 for SIGTERM, and as expected
Hi Eric
On 05/05/2020 20:58, Eric Blake wrote:
On 5/5/20 1:36 PM, Jonny Grant wrote:
Okay. That's confusing. The only value in hand being EEXIST then
that is the error to be reported. If this were repeated many times
then sometimes we would catch it as an actual directory.
lstat
On 04/05/2020 20:32, Bob Proulx wrote:
Jonny Grant wrote:
Paul Eggert wrote:
Jonny Grant wrote:
Is a more accurate strerror considered unreliable?
Current:
mkdir: cannot create directory ‘test’: File exists
Proposed:
mkdir: cannot create directory ‘test’: Is a directory
I don't
Hi!
On 03/05/2020 00:13, Paul Eggert wrote:
On 5/2/20 3:41 PM, Jonny Grant wrote:
Is a more accurate strerror considered unreliable?
Current:
mkdir: cannot create directory ‘test’: File exists
Proposed:
mkdir: cannot create directory ‘test’: Is a directory
I don't understand this comment
On 02/05/2020 20:47, Paul Eggert wrote:
On 5/2/20 6:26 AM, Jonny Grant wrote:
If developers have race conditions in their shell scripts
I've personally fixed a bug in the GNU mkdir command that was triggered by such
races. Core utilities should be reliable even when these races
On 01/05/2020 21:32, Paul Eggert wrote:
On 5/1/20 1:21 PM, Jonny Grant wrote:
yes, the fix pretty trivial for mkdir as you highlight EISDIR:
stat(), S_ISDIR(sb.st_mode), and set errno to EISDIR or output strerror(EISDIR)
That would introduce a race condition, and wouldn't behave correctly
On 01/05/2020 19:07, Paul Eggert wrote:
On 5/1/20 9:16 AM, Jonny Grant wrote:
rm: cannot remove 'test': Is a directory
That's because rm used unlink which failed with EISDIR, which is a different
error number.
yes, the fix pretty trivial for mkdir as you highlight EISDIR:
stat(), S_ISDIR
Hello!
Can this error message be clarified? The directory already exists, it is
not a file.
lib/mkdir-p.c:200 contains this line of code that triggers below:-
error (0, mkdir_errno, _("cannot create directory %s"), quote (dir));
As it's easy enough to know that the reason mkdir fails is
Hello
I noticed two different types of help output. Examples below. The later
seems a little hard to comprehend. Could they be unified?
$ getconf
Usage: getconf [-v specification] variable_name [pathname]
getconf -a [pathname]
$ getconf --help
Usage: getconf [-v SPEC] VAR
or:
On 15/08/17 12:45, Dmitry V. Levin wrote:
On Tue, Aug 15, 2017 at 08:19:13AM +0100, Jonny Grant wrote:
On 15/08/17 00:50, Paul Eggert wrote:
Jonny Grant wrote:
do you know which kernel API has this limitation?
All kernels have a limitation there to some extent, except perhaps the
Hurd
On 26/08/17 08:45, L A Walsh wrote:
Dmitry V. Levin wrote:
It's a security limit rather than a fixed buffer, see e.g.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da029c11e6b12f321f36dac8771e833b65cec962
Hmm, original poster had about 2.3MB of data.
The
On 15/08/17 00:50, Paul Eggert wrote:
Jonny Grant wrote:
do you know which kernel API has this limitation?
All kernels have a limitation there to some extent, except perhaps the
Hurd. Sorry, I don't know what the limits are.
Ok thank you.
I imagine kernels just need a dynamic API, so
Hello
Can this be resolved please? Seems a shame in 2017 on a machine with
16GB of ram I suffer this. Each filename is around 40 bytes.
Roughly 60,000 files
So total strings around 2.4 MBytes. Quite a small limit.
$rm jonny*.*
bash: /bin/rm: Argument list too long
rm (GNU coreutils) 8.25
On 01/07/17 00:54, Bernhard Voelker wrote:
tag 27538 notabug
close 27538
stop
On 06/30/2017 02:58 PM, Jonny Grant wrote:
Hello
Managed to create a broken link, but didn't get any warning.
Why would you expect to get a warning? Symlink links are just like
that - they are soft, loose
On 29/05/17 12:52, Pádraig Brady wrote:
On 28/05/17 01:54, Jonny Grant wrote:
Hello
I noticed a problem in the "man unlink" page.
The OPTIONS section is missing, and the Options are listed in the
DESCRIPTION section. Could the OPTIONS section be added?
Thank you, Jonny
I pres
Hello Paul
On 10/04/16 20:01, Paul Eggert wrote:
Jonny Grant wrote:
Hello
I noticed that cat doesn't have an accurate message in the following
use-case:
$ cat missingfile
cat: missingfile: No such file or directory
$ mkdir testdir
$ cat testdir
cat: testdir: Is a directory
Hello
I noticed that cat doesn't have an accurate message in the following
use-case:
$ cat missingfile
cat: missingfile: No such file or directory
$ mkdir testdir
$ cat testdir
cat: testdir: Is a directory
I wrote up the details of the ENOENT problem here:
28 matches
Mail list logo
