On 6/24/21 4:46 PM, F8ER F8ER wrote:
For example, `shuf -i 101-100 -n 1` returns nothing with the exit code
= 0 (unexpected).
Actually, it's the expected behavior. It's the same behavior as 'shuf -n
1 it means "output at most 1 line".
On 6/24/21 9:43 AM, Manson Thomas wrote:
So I've restarted my mac, and then uptime was returning correct
values... (after restart, and after latest BigSur update)
That's a relief. Thanks for confirming, and closing the bug report.
Dear GNU Developers,
Thank you very much for the project.
It seems, if the low range number is higher by 1 than the high number,
the program returns
nothing (with exit code = 0), while 102-100 results in an error and
100-100 returns 100 as expected.
For example, `shuf -i 101-100 -n 1`
Hi Paul,
same result (see below)
I have two other macbook :
* one on Catalina version (where BigSur is not offered), with
coreutils version 8.32 (so the same version), and that produces a
correct uptime value
* one on BigSur version, with coreutils v8.32, and that produces a
correct uptime value
On 6/24/21 1:26 AM, Manson Thomas wrote:
$ sudo dtruss /usr/bin/uptime
dtrace: system integrity protection is on, some features will not be available
dtrace: failed to execute /usr/bin/uptime: (os/kern) failure
Can you copy /usr/bin/uptime to /tmp/uptime and then dtruss /tmp/uptime?
On 6/24/21 7:50 AM, Pádraig Brady wrote:
We should be able to inotify_init() earlier in the process to avoid this
issue.
inotify_init can return 1025 even if called first thing, so we also need
to dup2 the result of early inotify_init down to 3 (or whatever), or at
least to check that it's
On Thursday, June 24, 2021 4:50:25 PM CEST Pádraig Brady wrote:
> Note the number of descriptors select() is waiting on in independent of the
> number of files. We should be able to inotify_init() earlier in the process
> to avoid this issue. I'll have a look.
Good idea! This could make it work
On 24/06/2021 15:26, Kamil Dudka wrote:
Hello,
As originally reported by Stepan Broz (CC'd), tail --follow crashes when it
is given too many files to follow, and ulimit -n is set to >1024.
FD_SET(wd, ) in tail_forever_inotify() writes beyond the stack-allocated
variable in case wd >=
Hello,
As originally reported by Stepan Broz (CC'd), tail --follow crashes when it
is given too many files to follow, and ulimit -n is set to >1024.
FD_SET(wd, ) in tail_forever_inotify() writes beyond the stack-allocated
variable in case wd >= FD_SETSIZE. Minimal example:
# mkdir dir
# cd
well you guess just about right about Apple not making it easy to debug ;)
$ /usr/bin/uptime
10:25 up 38 days, 40 mins, 3 users, load averages: 1.98 2.19 2.32
$ sudo dtruss /usr/bin/uptime
dtrace: system integrity protection is on, some features will not be available
dtrace: failed to
10 matches
Mail list logo
