| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Note: toy_exec() does an exact name match so fails given a path anyway,
it's just an optimization to avoid the binary search, but special casing
absolute path while very cheap isn't _correct_...
|
|
(I hit 0 paired with EAGAIN causing premature pipeline end many years
ago when a pipeline was Ctrl-Z then fg, may not still be possible with
modern kernels but I left that covered just in case.)
|
|
Other dd implementations always show the status on exit, whether success
or failure. Fix that by using xsigatexit() (and clarify the comment for
that function a little, since it didn't previously address the "at exit"
part of its behavior at all).
This also fixes SIGUSR1 behavior so that we show the status immediately
rather than on the next trip round the read/write loop.
Tested with `dd of=/dev/full`, sending SIGUSR1 twice from another shell
(to see the status immediately each time, without exiting), then hitting
^C (to see the status and then exiting), then restarting dd and hitting
enter (to see a write error followed by the status before exiting).
Bug: https://issuetracker.google.com/177017283
|
|
|
|
On Linux, struct statvfs' f_bsize and f_frsize seem to be
interchangeable. On macOS, they're wildly different. f_bsize is the
"preferred length of I/O requests for files on this file system"
(corresponding to statfs::f_iosize), and f_frsize is the "size in
bytes of the minimum unit of allocation on this file system"
(corresponding to statfs::f_bsize. POSIX appears to say nothing
about the interpretation of these fields, but man7.org's statvfs(2)
page is quite clear that statvfs::f_blocks, for example, is in units
of f_frsize, not f_bsize.
This is the only place in the tree where we use statvfs::f_bsize
(other than the stat(1) output that's supposed to be f_bsize and
that has a corresponding f_frsize dual anyway.
I've removed the Apple-specific #define f_frsize in portability.h
because that seems to have been from my previous attempt to understand
what was going on here. The output of the relevant stat(1) fields
on macOS are the same before/after this patch.
This makes toybox df's output match the system's df on a MacBook
Pro running macOS 11.2.1.
Tested on a Raspberry Pi 400 running Linux too, where I see no
change in the output before/after this patch.
|
|
|
|
Add a test, with comment that "make install_test" doesn't currently exist...
|
|
|
|
|
|
|
|
no argument returns NULL same as --opt without =
|
|
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.
|
|
We need <xlocale.h> for newlocale(3) on macOS, despite it being in POSIX 2008's <locale.h>. musl apparently doesn't have <xlocale.h>, so that's another trick
to teach to portability.h...
|
|
|
|
|
|
The FEXTRA field, indicated by bit 2 of the flag byte, contains
arbitrary extra data, prefixed by a 16-bit length value. The previous
code skipped over the length, but not the actual contents, breaking
decompression of certain files.
|
|
configurable.
|
|
Based loosely on the Plan9/Inferno utility, and a convenient way to go back
and forth between code points and utf8 sequences.
This patch also fixes a couple of bugs in wctoutf8 (and the tests for this
toy effectively serve as unit tests for wctoutf8/utf8towc).
|
|
|
|
|
|
Change 5109da9b3e6a898c8e0ad647303a1b375e3d97d3 caused test.test to call
chmod with mode `u+s+s` which passes on the host (where you have a
toybox test but a GNU chmod) but fails on Android where chmod is toybox
too.
Add the missing loop to string_to_mode(), which means this will also
affect other toys, but that seems like a feature (and, for example, GNU
mkdir also accepts a mode like `a=r+w+x`).
|
|
Can't use the same set_terminal() logic as ptys because it not displaying
data, it should just accurately copy it.
|
|
|
|
|
|
This makes it more likely that you can actually debug something like
"sed: bad regex: empty (sub)expression" or
"sed: bad regex: parentheses not balanced" from a build failure log,
where you don't necessarily know where the failure came from.
This also seems like it might be useful generally, although GNU grep
doesn't include this detail in its error messages, and busybox doesn't
even seem to notice that regcomp() failed?
(Realistically if the Android build team wants to move forward with "one
true regex implementation", we're going to have to add some GNU-isms to
the Android regex implementation. But we'd need to find them first! Note
that the two examples given above are real examples from failed buildbot
builds, but they occur early in the respective builds so there are
likely many more to look at after these. Interestingly, the first of the
two appears to be the more general case of something disallowed by POSIX
that xregcomp() already has a workaround for.)
|
|
I added a #include above this, which caused subtle breakages on 32-bit
systems. Move it to the top of the file to fix it and avoid making a
similar mistake in future.
|
|
One reason to use toybox on the host is to get the same behavior across
Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one
area where that doesn't quite work is that toybox uses the libc regular
expression implementation. That's fine, and mostly what users want, but
those folks trying to get the exact same behavior everywhere might want
to switch in a known regex implementation (bionic's NetBSD regex
implementation, say) for increased consistency.
That actually works pretty well, but portability.h has an #ifndef test
for REG_STARTEND before including <regex.h> that gets in the way. To
make up for that, this patch removes the unnecessary #include <regex.h>
from grep.c itself.
|
|
|
|
|
|
|
|
|
|
We need to *name = 0 explicitly for the !name && !statless case, so don't
need the +1 in memset that was only zeroing in the !name && statless case.
|
|
tar asks dirtree_path() to reserve space for a trailing '/', but recent
changes broke that for the case that was resolving to just a strdup().
Caught by `export ASAN=1` and `make test_tar`.
|
|
|
|
|
|
|
|
|
|
when passed in extra allocation length or else free() gets very unhappy.
|
|
|
|
|
|
broke the password: prompt.
|
|
The comma thing turned into an internationalization can of worms,
don't go there. Keep the "show megabytes on systems with >10G"
logic which includes not showing 0.0 for single digit values.
|
|
and use the comma format when selected even if <3 digits (no 0.0M)
|
|
|
|
This round trip occurs in practice with $KBUILD_BUILD_TIMESTAMP in
kernel builds.
|
|
Some of the grep tests were still failing because we weren't flushing
stdout --- xflush takes a bool that says whether to actually flush, so
we need to pass 1, not 0.
|
|
This is why the tests have been failing since
42303209f44a335025b9cd1dbe5dd2f3069f2e99.
|
|
|
