| Age | Commit message (Collapse) | Author |
|---|
|
This is why the tests have been failing since
42303209f44a335025b9cd1dbe5dd2f3069f2e99.
|
|
|
|
|
|
|
|
|
|
Heavily used long params under some contexts for already implemented
options:
chgrp/chown:
Add alias '--no-dereference' for '-h'
rmdir:
Add alias '--parents' for '-p'
|
|
|
|
|
|
Helps for terminals narrower than 80 columns (such as ConnectBot on a
current Android device).
|
|
This can still be pretty ragged because it just leaves space for the
longest name at the end of each line rather than measuring the name that
actually comes next, but at least with this change we never over-run.
I noticed this because ConnectBot on my current device gives me a
60-column terminal.
busybox seems to do this, though it seems to actually measure, judging
by how close it gets to the margin. That doesn't seem worth the effort
though?
|
|
Yeah, it means distclean doesn't delete _everything_, but in this case it's
intentional, and "remove the empty directory but not if it has contents"
isn't worth fighting with make's error reporting over.
|
|
The key issues here turned out to be that getty is responsible for
creating the file if it doesn't exist, and that the -H flag doesn't
control whether utmp is updated, but whether or not to override the
hostname within the utmp entry.
While I'm here switch to the more modern utx APIs that all the non-pending
parts of toybox use, and remove the duplication.
|
|
|
|
the first google hit for "android toybox"), and want toybox --help to
mention it. I was referred to https://github.com/landley/toybox/issues/50
So add a URL to toybox --help. While I was there, make unrecognized commands
(like toybox -?) suggest "toybox --help", move the install instructions
to the FAQ page (with a second link from toybox --help), and generally
tighten up the help text. Also, "toybox -*" is no longer a synonym for --long.
Oh, and I fixed some build dependencies when Config.in changes.
|
|
|
|
Rob's code supports more formats than mine did, so add the extra tests.
|
|
|
|
Requested in https://github.com/landley/toybox/issues/130, quoting an
old version of the toybox help. This is also supported by coreutils.
Set $LANG to C in the date tests so that they pass with TEST_HOST=1
(they were already failing for me, presumably related to a newer glibc).
|
|
|
|
This is a follow-on from 310eefe, addressing the case where sscanf fails
and returns -1.
|
|
|
|
has a build script that goes much faster with it, and added tests for it.
I reimplemented it a different way, and did SIGUSR1 and SIGUSR2 support.
|
|
|
|
Fixes #227.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The sprintf() call, while technically valid (17 bytes fits in an 18
byte allocation) trips Alpine fortify-headers due to checking for
allocations that could potentially overrun.
The call is pointless anyway -- as we are appending a constant to
another constant, it is better to just let the compiler do so and
calculate the size. This is supported by ISO C89 and later, and
thus any compiler that would be used to compile toybox.
Signed-off-by: Ariadne Conill <ariadne@dereferenced.org>
|
|
|
|
The glibc headers also provide that member, but s6_addr is the portable way.
This fixes compilation on musl libc.
Signed-off-by: Ariadne Conill <ariadne@dereferenced.org>
|
|
|
|
each day * Builds on each push
|
|
(Also fix -v output going to stderr when it shouldn't.)
|
|
|
|
|
|
|
|
|
|
This is sort of a hack because I want to move the individual tests to
subshells, which means they don't have a shared shell context. Functions
and variables not persisting into later tests is a good thing (test environments
polluting each other), but it makes accumulating FAILCOUNT more awkward.
|
|
This let me compare against the host for #225.
|
|
|
|
|
|
|
|
(Apologies for the length of this commit message, but it's not entirely
clear how we arrived at our present state, and right now all three of
toybox, busybox, and util-linux differ from each other. And it took a
week of arguments behind the scenes to agree on what we thought was the
right behavior, which seemed worth capturing for posterity.)
This reverts my change ef0546d4f536f42a57af4c32bd37f7fd752d10c2 from
2015. The commit message back then claimed:
For systems using /dev/rtcN, /dev/rtc0 isn't necessarily the RTC
that's used to provide the system time at boot time. We need to
search for the RTC whose /sys/class/rtc/rtcN/hctosys contains "1".
A few things to note here:
1. I can't find any historical motivation for this change. There's no
bug, there's no internal email thread, and I can't even find anything
referring to devices using anything other than /dev/rtc0.
2. It turns out (though this wasn't true at the time) that the kernel
since 4.19 interprets hctosys as the RTC that *did* set the clock,
not the RTC that *should* set the clock.
3. That's not an academic difference. If you have a cheap RTC that isn't
battery-backed, or you have an RTC whose battery died, and you're
using Linux 4.19 or later, you will boot with no RTC having hctosys=1.
4. An actual SoC vendor has hit this in practice.
My original toybox patch appears to be equivalent to code in the Android
frameworks, which -- under the auspices of the SoC vendor's bug --
I'm about to replace with code that checks "/dev/rtc" first, then
"/dev/rtc0", then fails hard. (Strictly, it's this copy of the search
that's causing the SoC vendor issues. AFAIK no-one's using
hwclock/rtcwake except interactively. And even if they are, Android
devices ship with [at least] two copies of toybox, so code/scripts on
the vendor partition will continue to run the vendor copy of toybox they
were developed against, and a newer toybox elsewhere on the system won't
affect them.)
All Android devices (and emulators) available to me at the moment use
/dev/rtc0, but supporting /dev/rtc gives a workaround for anyone who
really insists on using an RTC other than /dev/rtc0. That said, the
Generic Kernel Image (GKI) always assumes /dev/rtc0, so going forward
/dev/rtc0 is always the right choice.
I did consider making toybox hwclock try /dev/rtc, /dev/rtc0, and
/dev/misc/rtc -- and even wrote the code for that first -- but strace
shows that busybox and util-linux's hwclock implementations differ in
the order in which they try these (busybox tries /dev/rtc first,
util-linux tries /dev/rtc0 first). Given that util-linux seems like the
more canonical precedent, trying /dev/rtc0 and then falling back to
/dev/rtc would offer no advantage to Android users (and would seem to be
just another stumbling block in getting everyone to a world where
/dev/rtc0 is "the" system RTC).
Note that rtcwake is unaffected by all this, because the toybox and
util-linux implementations both default to only trying /dev/rtc0 already.
Bug: https://issuetracker.google.com/158051176
|
|
|
|
Found trying to run the libc++ tests.
For coreutils, `info chmod` says:
'chmod' ignores symbolic links encountered during recursive directory
traversals.
Bug: http://b/155809792
|
|
|
