| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
This patch does two things:
1. Enable line buffering for echo and yes. I found this through test
flakiness from the toybox xargs tests running in CI on devices where
"echo" is provided by toybox. For `echo y`, GNU echo does one write
of "y\n" but toybox echo was doing two writes, which makes it more
likely (4% on the heavily-loaded CI machines) for writes from the two
processes to be interleaved.
2. Fix line buffering on glibc if you're calling `toybox foo` rather
than `foo`. Otherwise we come through once and switch to unbuffered
mode, then again and switch to line buffered mode --- which doesn't
seem to actually work in glibc unless you specify a buffer (so
passing toybuf and sizeof(toybuf) works, but NULL and 0 doesn't).
I hit the second issue trying to reproduce the first issue on the desktop
rather than on Android.
(If you're scratching your head wondering "why yes(1) too, not just
echo(1)?", that represents a blind alley I went down when I mistook
which tool was in use. It seemed like the same principle should apply,
and it matches what other implementations do.)
|
|
I've been using hexedit quite a lot, mainly for _corrupting_ files, and
have been meaning to send this collection of changes for far too long
now. I saw a bug requesting editing in the ASCII pane (which this patch
_doesn't_ add), and wanted to get this sent in before it has to undergo
the third massive merge conflict of its existence...
The main "TODO" in this is that I never got round to implementing
searching for an arbitrary byte sequence. It seems like we ought to have
that feature, but personally I'm far more likely to jump to an offset or
to search for some ASCII. I haven't needed to search for arbitrary byte
sequences in all this time, so I'll fix this if/when I actually need
it...
* Enter (new) read-only mode rather than refusing to open read-only
files.
* More keys: page up/page down, home/end, and ctrl-home/ctrl-end for
beginning/end of file.
* Jump with ^J (or vi-like :). Enter absolute address or +12 or -40 for
relative jumps.
* Find with ^F (or vi-like /). No support for bytes, but useful for
finding text. (^G or n for next match, ^D or p for previous match.)
* Support all the usual suspects for "quit": vi-like q, desktop-like ^Q,
panic ^C, or even plain old Esc.
* The ASCII pane is made more readable by (hopefully) reasonable use of
color. Regular control characters are shown in red using the
appropriate letter (so a red A is 0x01, etc), printable characters are
shown normally, and top-bit set characters are just shown as a purple
question mark (since I couldn't come up with a better representation
that had any obvious value --- in my experience top-bit set characters
are either meaningless in ASCII, part of a UTF-8 sequence in modern
files, or in some random code page in ancient files). The choice of
red and purple was to deliberately make these not-actually-ASCII
characters slide into the background; before this patch they have so
many bright pixels (especially with the use of reverse video) that I
couldn't clearly see the *actual* ASCII content in the ASCII pane.
* Addresses are now shown in yellow. No real justification other than "it
looks nice".
* NUL bytes in the hex pane are shown dimmed. I find this helpful
especially when there's a lot of padding, and it can actually be a
useful clue when reverse engineering (you can "see" repeated patterns
more easily), but I can understand if this one's controversial.
* Errors are shown "vim style" in bold white text on a red background,
waiting briefly to ensure they're seen.
* The status bar shows the filename, whether the file is opened
read-only, the current offset into the file, and the total
length of the file.
* SIGWINCH handling has been added.
|
|
The new cpio test that uses setsid fails if you're using the toybox
setsid. Move the setpgrp() call before the vfork() but after the
setsid().
|
|
|
|
My patch to fix df behavior on macOS broke the stat build on macOS.
First off, we had %s and %S the wrong way round compared to coreutils,
though since Linux always seems to use the same value for both,
no-one will ever have noticed.
Annoyingly, Linux and macOS disagree about what statfs::f_bsize
means, and whether statfs::f_iosize and statfs::f_frsize exist (each
has one or the other, depending on what f_bsize *doesn't* mean to
them). This mess is presumably why statvfs exists.
Unfortunately, statvfs on macOS at least doesn't contain the file
system type information. So we either need to do *both* statfs()
and statvfs() for macOS, or we need to take into account the different
fields.
This patch adds an #ifdef outside of portability.h because I wasn't
sure we actually wanted to add statfs_best_transfer_size() and
statfs_real_block_size() functions to lib for this. But that's an
easy cleanup if desired.
|
|
|
|
|
|
|
|
|
|
Add new toy `base32`. Add tests for `base32`.
base32 is added by adapting the base64 encode/decode function to also do
base32 encoding/decoding. Then their respective main functions set up
the global parameter `n` to be the number of bits used in the encoding
(5 for base32 and 6 for base64) and `align` to align the result to a
certain length via padding. These are deliberately kept as parameters to
enable future expansion for other bases easily.
|
|
Note: can't put in portability.h because it's a linux/ include.
|
|
|
|
|
|
|
|
|
|
output depending on whether address was hex or decimal.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is consistent with the util-linux implementation.
|
|
This is consistent with the util-linux implementation.
|
|
Fix i2cdetect parameter reading so "last" value is read from correct argument.
|
|
The util-linux blkid (even if explicitly asked with -s) won't show you a
tag with no value.
|
|
|
|
(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
|
|
|
|
Yeah, this limits 32 bit support, but that's a "fix it properly in lib/args.c
or don't care" issue. Why work around it here when truncate -s doesn't?
|
|
Increase memory:swpd,free,cache to 7 characters
Increase swap:si,so to 5 characters
Increase system:in,cs to 5 characters
Sample output from Pixel 4 phone:
procs ------------memory------------ ----swap--- -----io---- ---system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
4 0 1111676 87896 6328 2268596 8152 11896 10712 14280 0 25712 31 21 46 3
17 0 1082788 224292 5972 2213996 73220 68908 2432 3948 1 26611 41 38 22 0
6 0 1127316 203196 5972 2225164 8980 53996 11796 788 0 25200 33 22 45 1
0 0 1133072 200984 5972 2225280 416 6260 52 88 0 8543 10 6 84 0
2 0 1128976 196976 5972 2225692 3588 0 340 800 0 5243 5 4 91 0
|
|
Bug: http://b/156292059
Signed-off-by: Wei Wang <wvw@google.com>
|
|
|
|
|
|
|
|
|
|
with memset() instead of = {}, and move TT.alarm to local variable.
|
|
Some of the bringup folks are debugging RTC issues and asked for this.
Rather than duplicate the weird xtzset dance with mktime, I've factored
that out into a new xmktime that takes a boolean for whether to use UTC
or local time.
Otherwise, the slight cleanup of hwclock.c is entirely optional. The
only functional change there is that util-linux 2.34's hwclock uses ISO
time format, which is the usual toybox preference anyway, so I've
switched it over to that rather than ctime(3).
Bug: http://b/152042947
|
|
In case I'm not yet in the running for the most pedantic change of this
release, I think the "days of the week are written with initial capitals
in English" subset of this patch is a strong contender.
(Found via `toybox help -a | ispell -l | sort | uniq`.)
|
|
|
|
I came here because the new -Wno-unreachable-code-loop-increment warning
didn't like the for loop on line 86. That loop is indeed not necessary.
Use strend() to do a string suffix match.
Use memmem() to search. It's available on macOS and Android by default,
but it's behind _GNU_SOURCE for glibc, so add that to portability.h.
Output the tags in the same order as the Debian modinfo.
I've left "parmtype" in even though the Debian modinfo doesn't output it
at all.
Also fix the tests so that they work on a device that has modules for
multiple kernels installed (like my laptop) --- make sure that the two
modules we pick come from the same kernel.
|
|
|
|
Also fix another bug where we were testing `set` twice.
Fixes https://github.com/landley/toybox/issues/172.
|
|
The e2fsprogs chattr(1) returns failure when it fails to do what was
asked of it, and so should we. Fixing this then reveals a lot of issues
with the tests that were being accidentally swept under the carpet.
The bulk of this patch is going through all the tests, removing the
duplicates and making the remaining tests more thorough.
I've tested this on ext4 and f2fs on a variety of 4.x and 5.x kernel
versions (but nothing older). We might need to reduce the list of
attribtues we try to toggle, but the more thorough tests use
well-supported attributes.
I've also fixed the -R test to actually involve a directory hierarchy.
|
|
When chattr fails in production, it helps to see what it was trying to
do. Reuse the lsattr format but without the '-'s.
Only read the flags if we have any intention of changing them:
`chattr -p 123` has no reason to read the flags.
Only write the flags back if they actually change: `chattr +a`
shouldn't do anything if that flag is already set, for example.
Switch -p and -v to perror_msg() instead of perror_exit() in case
they're used with -R.
(I suspect that the uses of DIRTREE_ABORT are mistakes given -R, but
I'll leave them until I actually hit this.)
|
