On 5/13/20 6:30 AM, Rob Landley wrote:
> P.P.P.P.P.S. readlink -q doesn't work in debian:
>
> $ ln -snf link link
> $ readlink -q link
> link
$ touch file
$ readlink -m file/dir
/home/landley/toybox/toybox/file/dir
That's not "missing".
$ echo -e 'one\ntwo\nthree' | rev -
On 5/14/20 6:48 PM, Ryan Prichard via Toybox wrote:
> FWIW, the GNU "uptime -s" reports my seconds as 31, whereas busybox and toybox
> alternate between 29 and 30.
It's ignoring the fractional part and rounding to a second to do integer math.
I'm personally ok with this. Is it breaking something
No, it's fine with me.
-Ryan
On Thu, May 14, 2020 at 5:38 PM Rob Landley wrote:
> On 5/14/20 6:48 PM, Ryan Prichard via Toybox wrote:
> > FWIW, the GNU "uptime -s" reports my seconds as 31, whereas busybox and
> toybox
> > alternate between 29 and 30.
>
> It's ignoring the fractional part and
http://landley.net/notes.html#02-05-2020
Let's see:
$ cat /proc/uptime
11514340.14 18323433.75
Um, I'm guessing first number is runtime and second is suspend time
(in seconds) since last reboot, toybox date -d @$(($(date
+%s)-18323433)) says I last rebooted near the start of October. Yeah,
strace suggests coreutils reads /proc/uptime while busybox and toybox
use sysinfo(2).
On Thu, May 14, 2020 at 4:49 PM Ryan Prichard wrote:
>
> FWIW, the GNU "uptime -s" reports my seconds as 31, whereas busybox and
> toybox alternate between 29 and 30.
>
> $ uptime -s
> 2020-05-11 13:58:31
>
>
FWIW, the GNU "uptime -s" reports my seconds as 31, whereas busybox and
toybox alternate between 29 and 30.
$ uptime -s
2020-05-11 13:58:31
$ for i in $(seq 5); do sleep 0.5; busybox uptime -s; /x/toybox/toybox
uptime -s; done
2020-05-11 13:58:30
2020-05-11 13:58:30
2020-05-11 13:58:29
